cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1474
Views
0
Helpful
7
Replies

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

Andrew Escher
Level 1
Level 1

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

7 Replies 7

Herbert Baerten
Cisco Employee
Cisco Employee

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

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

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

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

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

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

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: