NAT issue that just won't die

[WStoffel1]

I figured i'd start a new thread since this original problem dates back some time.  part of the problem was security levels were used initially way back when instead of interface acl's so i have these recurring nat issues, which i've just about resolved.

My problem now is really with 2 interfaces, Ex, and LV.  Right now i can get to devices on the Ex interface (192.168.180.x) from LV.  And i can get to devices on the LV interface (192.168.139.x) from the Ex interface.

I need to lock down traffic ONLY from LV->Ex to three specific IP's and a range of ports.  I have the object groups for both the ip's and ports:

object-group network ExchangeInternal

network-object host 192.168.180.11

network-object host 192.168.180.12

network-object host 192.168.180.25

object-group service Exchange_Services tcp

port-object eq 26

port-object eq 587

port-object eq 993

port-object eq 995

port-object eq www

port-object eq https

port-object eq imap4

port-object eq pop3

port-object eq smtp

Here's what i did:

access-list Exchange-In extended permit tcp 192.168.139.0 255.255.255.0 object-group ExchangeInternal object-group Exchange_Services

access-group Exchange-In in interface Ex

I had a limited window to do this so.....

The two addresses i was using to test behind each interface were (Ex) 192.168.180.25 and (LV) 192.168.139.7, and before any changes i could ping each way and get replies.  After adding the two lines above:

From 192.168.139.7 a ping to 192.168.180.25 kept working as expected.

A ping from 192.168.180.25 to 192.168.139.7 stopped working.

The only other thing i could do in the time frame was packet tracers, so i have that as well showing the failures if needed.

I guess my first question, on applying an interface acl IN the Ex interface, what am i missing that Out traffic stopped?

Thank you..

[Jouni Forss]

Hi,

I am not sure if that is the only ACL rule in the ACL that is applied to the interface "Ex"? I would presume that its not?

If it is, then it would mean that only that traffic is allowed and rest traffic is blocked because of the implicit Deny All in the end of all interface ACLs.

To my understanding if you have "inspect icmp" and "inspect icmp error" enabled on the firewall then those ICMP return messages would be allowed back automatically.

If this is not the case then I guess you could try adding this ACL rule to the "Ex" interfaces ACL

access-list Exchange-In permit icmp 192.168.139.0 255.255.255.0 object-group ExchangeInternal echo-reply

And see if that helps at all.

Naturally if none of the above were the case then it would probably help seeing the output of those "packet-tracer" commands you used.

- Jouni

[WStoffel1]

No it is the only interface acl applied...the initial issue was i only had one way communication between the interfaces due to security levels.  Now they both have theirs set to 90 (dont ask) but nothing is at 100

Here's the relevant config.  With this i can pass traffic bidirectional across the two interfaces.  All my servers on 180 can see my servers on 139 and back.  Which is good, but it's wide open.

interface GigabitEthernet0/3.139

vlan 139

nameif lv

security-level 90

ip address 192.168.139.1 255.255.255.0 standby 192.168.139.2

!

interface GigabitEthernet0/3.180

vlan 180

nameif Ex

security-level 90

ip address 192.168.180.1 255.255.255.0 standby 192.168.180.2

!

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

!

static (Ex,lv) 192.168.180.0 192.168.180.0 netmask 255.255.255.0

static (lv,Ex) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

!

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect netbios

  inspect rsh

  inspect rtsp

  inspect skinny

  inspect sqlnet

  inspect sunrpc

  inspect tftp

  inspect xdmcp

  inspect pptp

  inspect ipsec-pass-thru

  inspect icmp

  inspect h323 h225

  inspect h323 ras

service-policy global_policy global

Since this is wide open i thought i could add the follwing to restrict traffic to the defined (exchange) ports and addresses from 139>180:

access-list Exchange-In extended permit tcp 192.168.139.0 255.255.255.0 object-group ExchangeInternal object-group Exchange_Services

!

access-group Exchange-In in interface Ex

Prior to the above two lines, packet tracer shows the following as allowed.  When i apply the acl i get this instead (let me know if you need to see the working as well):

packet-tracer input Ex tcp 192.168.180.25 32000 192.168.139.7 25

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xac7a7eb0, priority=1, domain=permit, deny=false

hits=1775854009, user_data=0x0, cs_id=0x0, l3_type=0x8

src mac=0000.0000.0000, mask=0000.0000.0000

dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

static (lv,Ex) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

  match ip lv 192.168.139.0 255.255.255.0 Ex any

    static translation to 192.168.139.0

    translate_hits = 106535, untranslate_hits = 6

Additional Information:

NAT divert to egress interface lv

Untranslate 192.168.139.0/0 to 192.168.139.0/0 using netmask 255.255.255.0

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xace27010, priority=11, domain=permit, deny=true

hits=139, user_data=0x5, cs_id=0x0, flags=0x0, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Result:

input-interface: Ex

input-status: up

input-line-status: up

output-interface: lv

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

[WStoffel1]

here it is working, without the acl applied:

packet-tracer input ex tcp 192.168.180.25 32000 192.168.139.7 25

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

static (lv,Ex) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

  match ip lv 192.168.139.0 255.255.255.0 Ex any

    static translation to 192.168.139.0

    translate_hits = 120755, untranslate_hits = 12722

Additional Information:

NAT divert to egress interface lv

Untranslate 192.168.139.0/0 to 192.168.139.0/0 using netmask 255.255.255.0

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype:

Result: ALLOW

Config:

static (Ex,lv) 192.168.180.0 192.168.180.0 netmask 255.255.255.0

  match ip Ex 192.168.180.0 255.255.255.0 lv any

    static translation to 192.168.180.0

    translate_hits = 12807, untranslate_hits = 164561

Additional Information:

Static translate 192.168.180.0/0 to 192.168.180.0/0 using netmask 255.255.255.0

Phase: 8

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (Ex,outside) tcp 7.x.x.207 www 192.168.180.25 www netmask 255.255.255.255

  match tcp Ex host 192.168.180.25 eq 80 outside any

    static translation to 7.x.x.207/80

    translate_hits = 131, untranslate_hits = 5927

Additional Information:

Phase: 9

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

static (lv,Ex) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

  match ip lv 192.168.139.0 255.255.255.0 Ex any

    static translation to 192.168.139.0

    translate_hits = 120757, untranslate_hits = 12724

Additional Information:

Phase: 10

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (lv,dmz) 192.168.139.0 192.168.139.0 netmask 255.255.255.0

  match ip lv 192.168.139.0 255.255.255.0 dmz any

    static translation to 192.168.139.0

    translate_hits = 5296, untranslate_hits = 9332

Additional Information:

Phase: 11

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 12

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 583591158, packet dispatched to next module

Phase: 13

Type: ROUTE-LOOKUP

Subtype: output and adjacency

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.139.7 using egress ifc lv

adjacency Active

next-hop mac address 0050.568a.3c77 hits 150

Result:

input-interface: Ex

input-status: up

input-line-status: up

output-interface: lv

output-status: up

output-line-status: up

Action: allow

[Jouni Forss]

Hi,

Correct if I am wrong but to me it seems that you have applied an ACL to the "Ex" interface which source address belong to the "Lv".

interface GigabitEthernet0/3.180

vlan 180

nameif Ex

security-level 90

ip address 192.168.180.1 255.255.255.0 standby 192.168.180.2

access-list Exchange-In extended permit tcp 192.168.139.0  255.255.255.0 object-group ExchangeInternal object-group  Exchange_Services

access-group Exchange-In in interface Ex

So the source address will never be from 192.168.139.0/24 since the "Ex" network is 192.168.180.0/24

So it seems to me that you have to switch the source and destiantion network in the ACL.

But also I am wondering if the above is truly the COMPLETE ACL then that would mean that all outbound traffic from behind "Ex" would be denied. Actually at the moment it should be as the only permit rule is using wrong source network.

- Jouni

[WStoffel1]

Wait a second, did i get all twisted up? 

"But also I am wondering if the above is truly the COMPLETE ACL then that would mean that all outbound traffic from behind "Ex" would be denied."

-this is in fact what happened.

I'm trying to restrict traffic originating from 192.168.139.0 to 192.168.180.0, so that the 139 network can only get to 3 ip addresses (and specified ports as well) on the 180 network.  WITHOUT affecting traffic outbound from 180.

Doesn't that make the source 192.168.139.0/24?

In the broad view, an Exchange server at 192.168.139.7 needs to be able to communicate with the multiple servers at 192.168.180.0/24.  Communication out from 192.168.180.0/24 should be allowed in it's entirety.

[Jouni Forss · Accepted solution]

Argh, my head hurts well mostly because of not eaten anything yet and trying to look at configurations.

So lets start from beginning

You have the following interfaces which are directly connected to their networks

interface GigabitEthernet0/3.139

vlan 139

nameif lv

security-level 90

ip address 192.168.139.1 255.255.255.0 standby 192.168.139.2

!

interface GigabitEthernet0/3.180

vlan 180

nameif Ex

security-level 90

ip address 192.168.180.1 255.255.255.0 standby 192.168.180.2

You say above that you want to limit traffic from network 192.168.139.0/24 to network 192.168.180.0/24 to only specific destination hosts and services.

So naturally the place where we control that traffic is where its sourced from. Network 192.168.139.0/24 according to the above interface configuration is located on interface "lv" and NOT interface "Ex"

So we need an inbound ACL on the interface "lv" to control so that network 192.168.139.0/24 can only access certain hosts and services on the network 192.168.180.0/24 which is located on the interface "Ex"

If we further presume that

• Interface "lv" had no ACL prior to this
• Traffic rules should be allowed to everywhere else

Then you need to configure something like this

access-list LV-IN remark Allow traffic to certain Ex hosts

access-list LV-IN permit tcp 192.168.139.0 255.255.255.0 object-group ExchangeInternal object-group Exchange_Services

access-list LV-IN remark Deny All Other traffic to network Ex

access-list LV-IN deny ip 192.168.139.0 255.255.255.0 192.168.180.0 255.255.255.0

access-list LV-IN remark Allow all other traffic

access-list LV-IN permit ip 192.168.139.0 255.255.255.0 any

access-group LV-IN in interface lv

Though since you have to this day only used the "security-level" value to determine where the "lv" network can connect to, you might need to add some "deny" statements before the rule that allows all other traffic.

- Jouni

[WStoffel1]

I was all twisted up, because i was looking at it inbound to EV, it needed to be ON the ev interface...not the source interface.  ugggh.

as always, thanks.

I'll post back the results after I can do the config after hours, but looking at it, i'm quite sure this is correct

Thanks.

[Jouni Forss]

Hi,

I managed to almost miss the most important rule in the above ACL. This is to block all other traffic to the network 192.168.180.0/24 from the network 192.168.139.0/24

I edited it to my above reply with RED

- Jouni

[WStoffel1]

Hahahaha i was just about to ask after looking at it for several more minutes...

[WStoffel1]

100% dead on the money!

Now to wrap my head around why this worked IN interface lv.  Lv is the source, ex the destination so the flow of traffic is lv>ex which implies out.  Now my head hurts.

I tested access-group LV-IN out interface lv, lv to ex remained unchanged and i could still ping addresses on 192.168.180.0/24 from 139.0.  But i could no longer go the reverse   Not good in either case.

Regardless of me grasping it for now, it's up and working and i'm very appreciative!  Thanks.

[Jouni Forss]

Hi,

I remember wondering the same thing when I first started configuring some ACLs on routers and firewalls.

The direction in which the ACL is attached to an interface can be a bit missleading.

You will be always thinking the direction from the perspective of that single interface. When a user behind an interface initiates a connection and sends the first packet, in what direction does that traffic flow? It will naturally be "in" / Inbound traffic to the interface.

An "out" / Outbound ACL would be used to control traffic that is leaving an interface towards whatever is behind that interface.

I personally use only "in" / Inbound ACLs (and I would imagine majority of users do) on the ASA interfaces. These inbound ACLs will then control all the connection forming and traffic from behind those interfaces.

- Jouni

[WStoffel1]

You need to write an ASA book.

Thank you.