topic Problem with Hairpinning on ASA in Network Security

Problem with Hairpinning on ASA

baskervi — Tue, 12 Mar 2019 04:52:09 GMT

We have an ASA that needs to reroute an ASA to another firewall on the ASA's internal interface. The remote IPs are 10.12.14.0 / 24, so I've added the route to the ASA using "route inside 10.12.14.0 255.255.255.0 192.168.1.252", added "same-security-traffic permit intra-interface", and added the NAT statement "static (inside,inside) 192.168.1.0 192.168.1.0 netmask 255.255.255.0 norandomseq". Traffic is still not flowing but will if I put a static route into each of the local hosts. I've attached the packet tracer, but what confuses me is that phase 8 using "static (inside,inside)", phase 9 uses a static to our private cloud, and phase 11 uses yet another nat statement where the whole process fails. Can someone please help me figure out why traffic is going through so many nat processes and failing? The ASA is running 8.2(2).

ASA(config)# packet-tracer inp inside icmp 192.168.1.10 8 0 10.12.14.196

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 10.12.14.0 255.255.255.0 inside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group INSIDE-TEMP in interface inside
access-list INSIDE-TEMP extended permit ip any any
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: DEBUG-ICMP
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype:
Result: ALLOW
Config:
static (inside,inside) 192.168.1.0 192.168.1.0 netmask 255.255.255.0 norandomseq
match ip inside 192.168.1.0 255.255.255.0 inside any
static translation to 192.168.1.0
translate_hits = 229, untranslate_hits = 710
Additional Information:
Static translate 192.168.1.0/0 to 192.168.1.0/0 using netmask 255.255.255.0

Phase: 9
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) 192.168.99.0 access-list CBEYOND-NAT
match ip inside 192.168.1.0 255.255.255.0 outside 10.216.14.64 255.255.255.224
static translation to 192.168.99.0
translate_hits = 1326, untranslate_hits = 414582
Additional Information:

Phase: 10
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
match ip inside any inside any
dynamic translation to pool 1 (No matching global)
translate_hits = 1639, untranslate_hits = 0
Additional Information:

Result:
input-interface: inside
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

Hi Baskervi, The packet

Harvey Ortiz — Tue, 07 Oct 2014 04:47:45 GMT

Hi Baskervi,

The packet tracer shows a drop due to RPF, it seems we are missing the global statement:

global (inside) 1 interface

Try adding that command and attach a new packet tracer.

Also try with real traffic.

Please remember to rate and select the correct answer.

Hi,As Harvey pointed out

Vibhor Amrodia — Tue, 07 Oct 2014 07:33:36 GMT

Hi,

As Harvey pointed out earlier , if you want to translate the addresses to the Interface inside IP , the above step should be good.

If you don't want to translate , you would have to add a NAT-EXEMPT on this inside interface to prevent it from using the :-

nat (inside) 1 0.0.0.0 0.0.0.0 >> As this is WIDE open for any IP

NAT exempt would be something like this:-

nat (inside) 0 access-list exempt

access-list exempt permit 192.168.1.0 255.255.255.0 10.12.14.0 255.255.255.0

access-list exempt permit 10.12.14.0 255.255.255.0 192.168.1.0 255.255.255.0

Make the NAT statement much more specific

Thanks and Regards,

Vibhor Amrodia

I had actually tried "global

baskervi — Tue, 07 Oct 2014 15:29:35 GMT

I had actually tried "global (inside) 1 interface" yesterday, but it still didn't work as shown in the following. However, I took it out because I created a static NAT rule, and it makes absolutely no sense to me why it would try the static NAT rule and then use the PAT rule. I've also tried with real traffic, which works with a static route on the server.

Phase: 11
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
match ip inside any inside any
dynamic translation to pool 1 (192.168.1.1 [Interface PAT])
translate_hits = 437, untranslate_hits = 0
Additional Information:

Just another thought... I had

baskervi — Tue, 07 Oct 2014 16:07:20 GMT

Just another thought... I had done this yesterday for just the top line and not the bottom line of your exempt access list entries. The server was able to ping the remote system for a couple minutes, then the timeouts started occurring. No hosts would able to access the remote locationl However, I put both lines in today, and it works, but I'm not sure why the second line would even matter as asymmetrical routing is occurring (into our firewall, into theirs, but the return traffic only comes from theirs directly to the host). I configured TCP state bypass, which I realize doesn't do anything for ICMP, but this is at least working for the moment. Thanks for your help.

This is a completely separate question, but the ASA doesn't appear to send ICMP redirections as the routers do. Is there a way to change this behavior?