Hairpinning, VPN and NAT

[jerry.henzel]

Having some issues and looking for suggestions.  I am working off the document (http://www.cisco.com/en/US/docs/security/asa/asa91/configuration/firewall/asa_91_firewall_cli.pdf) on Pages 3-24 & 3-25.  In my lab setup all is working except for being  able to ping from the vpn cient to the network bethind the second ASA.

I have gone over the configs and checked vs the examples but obviously I am missing something.

VPN client in on ASA2.

My configs are attached with a few parts scrubbed.

An ICMP trace shows:

ICMP echo request from outside:10.10.120.1 to outside:192.168.16.50 ID=2 seq=12582 len=32

Running a packet trace (packet-tracer input outside icmp 10.10.120.1 0 0 192.168.15.50) shows:

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group OUTSIDE_IN in interface outside

access-list OUTSIDE_IN extended permit icmp any any

Additional Information:

Phase: 3

Type: NAT

Subtype:

Result: ALLOW

Config:

object network retail_vpn

nat (outside,outside) dynamic interface

Additional Information:

Phase: 4

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (nat-xlate-failed) NAT failed

Something is either not being natted properly or the return path is a problem but I cannot put my finger on it.

Anyone with suggestions

Thanks

Jerry

[Jouni Forss · Accepted solution]

Hi,

I assume that there is a typo in the "packet-tracer" destination IP address because I cant find a reference to that IP/subnet in the configuration.

Can you try the "packet-tracer" in a little bit different format

packet-tracer input outside icmp 10.10.120.1 8 0 192.168.16.50

The difference are the Type and Code numbers after the source IP address. Now it simulates an ICMP Echo. The previous format of the command might have caused the NAT failure result.

I assume that you are trying to forward the traffic to the L2L VPN connection.

Then you are already seem to have the correct NAT configuration. But it seems to me that you are also missing the these source/destination network from the L2L VPN configuration.

access-list vpn_inside extended permit ip object retail_vpn object riverroad_inside

Same on the ASA1

access-list vpn_inside extended permit ip object riverroad_inside object retail_vpn

Can you check the above things out and let me know if those helped with the situation.

- Jouni

[jerry.henzel]

Hi Jouni

Thanks for the reply and assistance.  In short, the ACL's did it.  Long version below

I assume that there is a typo in the "packet-tracer" destination IP address because I cant find a reference to that IP/subnet in the configuration.

Correct, I made a typo - I have a host behind ASA2 (192.168.16.50) which is on the riverroad_inside side

asa2(config)# sh run obj net                                              

object network retail_inside

subnet 192.168.18.0 255.255.255.0

object network riverroad_inside

subnet 192.168.16.0 255.255.255.0

description Inside network at RR

object network retail_pci_inside

subnet 192.168.17.0 255.255.255.248

description PCI hosts on inside at Retail

object network riverroad_pci_inside

subnet 192.168.20.0 255.255.255.248

description PCI hosts on insde at RR

object network retail_vpn

subnet 10.10.120.0 255.255.255.224

description External VPN to Retail

packet-tracer input outside icmp 10.10.120.1 8 0 192.168.16.50

The output is below and it works as expected.  I had sent an echo-reply code instead of just an echo.  I assumed both would work.  In retrospect they both do once the ACL issues below was resolved.

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 2

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: DEBUG-ICMP

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 30717, 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

I assume that you are trying to forward the traffic to the L2L VPN connection.

Correct - see above

access-list vpn_inside extended permit ip object retail_vpn object riverroad_inside

Same on the ASA1

access-list vpn_inside extended permit ip object riverroad_inside object retail_vpn

The addition of these 2 ACL's on the respective sides did the trick.

Thanks

Best Regards

Jerry

PS With the ACL's in place both echo and echo-reply work as expected in packet-tracer