%ASA-5-305013: Asymmetric NAT rules matched for forward and reve

Andrew Escher · ‎12-21-2011

Trying to NAT traffic over a VPN. NAT is happening one way

##################################

access-list AHI-crypto extended permit ip object-group AHI-L object-group AHI-R

nat (inside,outside) source static AHI-L AHI-NAT-R destination static AHI-R AHI-R

show nat

Manual NAT Policies (Section 1)

1 (inside) to (outside) source static AHI-L AHI-NAT-R destination static AHI-R AHI-R

translate_hits = 1, untranslate_hits = 0

######################################

packet-tracer input inside tcp 10.64.0.15 4444 192.168.168.100 30000

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.168.100 255.255.255.255 outside

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside_access_in in interface inside

access-list inside_access_in extended permit ip any any

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: FILTER

Subtype: filter-url

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: FILTER

Subtype: filter-https

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside,outside) source static AHI-L AHI-NAT-R destination static AHI-R AHI-R

Additional Information:

Static translate 10.64.0.15/4444 to 10.128.0.6/4444

Phase: 7

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

#################################################

^

packet-tracer input outside tcp 192.168.168.100 4444 10.64.0.15 30000

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 10.64.0.0 255.255.0.0 inside

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

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

#############################################

I can't see to figure out were it is being dropped.

I've tried adding the following ACL in addition to the above ACL as well as alone.

access-list AHI-crypto extended permit ip object-group AHI-L object-group AHI-NAT-R

###########################

here are the results

packet-tracer input inside tcp 10.64.0.15 4444 192.168.168.100 30000

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.168.100 255.255.255.255 outside

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside_access_in in interface inside

access-list inside_access_in extended permit ip any any

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: FILTER

Subtype: filter-url

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: FILTER

Subtype: filter-https

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside,outside) source static AHI-L AHI-NAT-R destination static AHI-R AHI-R

Additional Information:

Static translate 10.64.0.15/4444 to 10.128.0.6/4444

Phase: 7

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

################################

packet-tracer input outside tcp 192.168.168.100 4444 10.64.0.15 30000

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 10.64.0.0 255.255.0.0 inside

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

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

Herbert Baerten · ‎12-27-2011

Hi Andrew,

NAT happens before encryption (and after decryption) so the crypto ACL needs to match the translated traffic:

access-list AHI-crypto extended permit ip object-group AHI-NAT-R object-group AHI-R

BTW you cannot use packet-tracer to simulate traffic that arrives over a vpn tunnel. What you can do is run a capture on the outside interface, with the "trace" option, and then use "show capture " to identify an inbound ipsec packets, and then "show capture packet trace" to get a "packettracer-like" output for that packet.

hth

Herbert

Andrew Escher · ‎12-28-2011

side1:

name 5.6.7.8 VendorName

object-group network VendorName-R

network-object host 192.168.1.10

object-group network VendorName-NAT-R

network-object host 10.1.0.2

object-group network VendorName-L

network-object host 10.1.1.3

access-list VendorName-crypto extended permit ip object-group VendorName-NAT object-group VendorName-R

nat (inside,outside) 1 source static VendorName-L VendorName-NAT-R destination static VendorName-R VendorName-R

In the above example, what would the other sides crypto look like? Does it need to have the NAT in the crypto? Or is the below correct?

side 2:

name 8.7.6.5 VendorName

object-group network VendorName-R

network-object host 10.1.1.3

object-group network VendorName-L

network-object host 192.168.1.10

access-list VendorName-crypto extended permit ip object-group VendorName-L object-group VendorName-R

nat (inside,outside) 1 source static VendorName-L VendorName-L destination static VendorName-R VendorName-R

Herbert Baerten · ‎12-28-2011

The remote side (side2) is not aware of the NAT taking place, so it is only aware of the 10.1.0.2 address

In other words, side 2 should have:

object-group network VendorName-R

network-object host 10.1.0.2

object-group network VendorName-L

network-object host 192.168.1.10

access-list VendorName-crypto extended permit ip object-group VendorName-L object-group VendorName-R

nat (inside,outside) 1 source static VendorName-L VendorName-L destination static VendorName-R VendorName-R

BTW I assume your naming convention is based on L=Local, R=Remote which I personally find a bit confusing because the same name has a different meaning on each side. I suppose it's just personal preference but assuming side1 is in Boston and side2 in Chicago I would rather configure side2 as follows:

object-group network Boston-NAT

network-object host 10.1.0.2

object-group network Chicago

network-object host 192.168.1.10

access-list VendorName-crypto extended permit ip object-group Chicago object-group Boston-NAT

nat (inside,outside) 1 source static Chicago Chicago destination static Boston-NAT Boston-NAT

(and similarly on side1).

Then it becomes clear that the ACL is the exact mirror of the peer's ACL.

hth

Herbert

Andrew Escher · ‎12-28-2011

The Local and Remote are due to the fact I dont have access to the other side. I only see side 1 which for me is local.

Chicago Internet Boston

10.1.1.3 ------ 5.6.7.8 <-------> 8.7.6.5 ------- 192.168.1.10

The goal is to have Boston look like a 10.1.0.2 network to Chicago with Boston being none the wiser.

Chicago would send information to 10.1.0.2

Boston would send information to 10.1.1.3

Herbert Baerten · ‎01-11-2012

Ok that makes it a bit more clear

so we have:

object-group network Chicago

network-object host 10.1.1.3

object-group network Boston-NAT

network-object host 10.1.0.2

object-group network Boston

network-object host 192.168.1.10

And if I understood correctly this time, you want to destination NAT:

nat (inside,outside) 1 source static Chicago Chicago destination static Boston-NAT Boston

So the crypto ACL becomes:

access-list cryptoACL extended permit ip object-group Chicago object-group Boston

And on the Boston side, they would do no NAT (or identity NAT):

nat (inside,outside) 1 source static Boston Boston destination static Chicago Chicago

and their crypto ACL would be

access-list cryptoACL extended permit ip object-group Boston object-group Chicago

so they're effectively unaware of the NAT being done on Chicago side.

Does this help?

Herbert

Andrew Escher · ‎01-12-2012

I ended up getting TAC and a local SE involved.

This is what we ended up with.... What is the diffrence between what you posted and what we are currently using?

Chicago:

name 5.6.7.8 Boston

object-group network Boston-R

network-object host 192.168.1.10

object-group network Boston-NAT

network-object host 10.1.0.2

object-group network Chicago-L

network-object host 10.1.1.3

access-list Boston-crypto extended permit ip object-group Chicago-L object-group Boston-R

nat (inside,outside) 1 source static Chicago-L Boston-NAT destination static Boston-R Boston-R

nat (outside,inside) 1 source static Boston-R Boston-NAT destination static Chicago-L Chicago-L

Boston:

name 8.7.6.5 Chicago

object-group network Chicago-R

network-object host 10.1.1.3

object-group network Boston-L

network-object host 192.168.1.10

access-list Chicago-crypto extended permit ip object-group Boston-L object-group Chicago-R

Herbert Baerten · ‎01-13-2012

Hi Andrew,

ok sorry I couldn't get back to you sooner.

Now what's different between this config and mine? Not much

You have:

nat (outside,inside) 1 source static Boston-R Boston-NAT destination static Chicago-L Chicago-L

and I have:

nat (inside,outside) 1 source static Chicago Chicago destination static Boston-NAT Boston

which, if you look closely and you keep in mind that NAT rules are bi-directional, does exactly the same - I'm saying for traffic from Chicago to Boston-NAT, we need to translate Boston-NAT into Boston, while you are saying that for traffic from Boston to Chicago, Boston needs to be translated into Boston-NAT.

So this is just personal preference, neither is better than the other.

What puzzles me however is this other line you have:

nat (inside,outside) 1 source static Chicago-L Boston-NAT destination static Boston-R Boston-R

IMHO this is incorrect because it's saying "for traffic from 10.1.1.3 to 192.168.1.10, translate 10.1.1.3 to 10.1.0.2" and I don't think that that's what you want.

Of course you won't see any negative effect of this incorrect rule because it only affects traffic from 10.1.1.3 to 192.168.1.10, and I guess there is none of that because your inside host is sending to 10.1.0.2

Personally I would still clean this up and remove that line though.

hth

Herbert

BTW did you know you can open a TAC case directly from a CSC discussion thread ? This way the TAC engineer automatically gets all the information from the thread, and he or she can post the solution back to the thread.

%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection denied due to NAT reverse path failure. IN 8.4.2