Hairpinning and internal routing with an ASA 5505

bobismighty · ‎01-07-2011

So, I've got a routing/nat issue that I need some help with. I've attached an image to give you a visual view of the network(dumbed down quite a bit). Hopefully this is the right forum section to post this in.

On our office network we have two Ciscos. One is our ASA 5505 which we manage and connects to the internet. The other is a Nuvox(Windstream) Cisco that connects to an MPLS that goes to a remote office. The MPLS is only for phone traffic on that remote segment to get to the phone server in the main office.
Currently, our phone system has a gateway of 172.16.0.2, which is the MPLS router. Unfortunately, that router has no access to the internet; just to the MPLS. I'd like to make it so that I can set the gateway of the phone system to 172.16.0.1(ASA), so that it can get to the internet, and then have the ASA know to route traffic for the remote subnet(172.16.1.0/24) to the MPLS router at 172.16.0.2.

I'm new to the idea of hairpinning, but I got the ASA configured to actually work and forward traffic to 172.16.0.2 when the destination is 172.16.1.0/24. Unfortunately, one of the NAT commands breaks the local network because the ASA sends out ARP packets to everything, pairing its MAC address with every IP in the 172.16.0.0/24 range. If you look in the arp cache of any computer on the 172.16.0.0/24 network, every entry has the MAC address of the ASA.

Here are the commands that I added to the ASA. Like I said, these commands worked, technically, but caused the ARP mayhem. Once I realized which command it was, it made sense and I should have known, but I don't know what to do to fix it. The first nat static command is what does it in.

access-list acl_inside extended permit ip 172.16.1.0 255.255.255.0 172.16.0.0 255.255.255.0
access-list acl_inside extended permit ip 172.16.0.0 255.255.255.0 172.16.1.0 255.255.255.0
no nat-control
global (inside) 1 interface
static (inside,inside) 172.16.0.0 172.16.0.0 netmask 255.255.255.0
static (inside,inside) 172.16.1.0 172.16.1.0 netmask 255.255.255.0
route inside 172.16.1.0 255.255.255.0 172.16.0.2 1
no inspect sip

Federico Coto Fajardo · ‎01-08-2011

Hi,

What kind of switch you have between the Phone Server and the ASA?

The switch should know the MAC address of every device in the 172.16.0.0/24 associated with the correct IP.

The ASA will answer to ARP requests when trying to get to 172.16.0.0/24 as well, because it is configured to hairpin the traffic, but should be only when coming from another subnet (172.16.1.0/24 for example).

Can you post the ARP entry on the ASA for the 172.16.0.0/24 computers? show arp

Federico.

robert.horrigan · ‎01-08-2011

Can you add a default route on your router pointing to the PIX?

bobismighty · ‎01-10-2011

Hey guys, thanks for the replies. Sorry for my late response, I've been away for the weekend.

As far as the router goes, I can't change anything there. That's managed by Windstream and they won't add any routes for me. I already tried

Let me see if I can get the arp table of the ASA with and without the hairpinning in place. I'll post back with that.

Someone mentioned disabling ProxyArp on the ASA to combat the ARP problem. Do you think that would work? Will that screw up anything else? I just don't want to break our site-to-site VPN or anything else.

Thanks!

bobismighty · ‎01-10-2011

Alright, here's the arp table before and after adding the nat commands. BTW - the switch in between them is a 3com managed switch. Can't remember what model though off the top of my head.

Before:

router# show arp
        inside 172.16.0.69 0015.c583.6b69 10
        inside 172.16.0.10 000c.2953.bbae 21
        inside 172.16.0.66 0024.e80c.9677 21
        inside 172.16.0.90 0011.1135.a372 29
        inside 172.16.0.6 0030.4df4.e06c 29
        inside 172.16.0.14 000c.29b4.9cba 36
        inside 172.16.0.7 0030.4df4.e05d 38
        inside 172.16.0.20 000c.2997.7ef9 52
        inside 172.16.0.76 0015.afdd.9949 53
        inside 172.16.0.70 d830.629f.3545 87
        inside 172.16.0.55 0025.64cf.3554 130
        inside 172.16.0.114 0007.e978.07a8 206
        inside 172.16.0.13 00c0.9f37.8209 342
        inside 172.16.0.241 98fc.1198.6442 414
        inside 172.16.0.8 00c0.b750.41d3 429
        inside 172.16.0.11 0022.1928.e53c 510
        inside 172.16.0.88 0011.24bf.7e14 675
        inside 172.16.0.68 0025.004e.4e61 965
        inside 172.16.0.104 0024.36a4.3cff 965
        inside 172.16.0.5 0030.4df4.e7b2 1269
        inside 172.16.0.59 7c6d.62de.62b9 1369
        inside 172.16.0.52 0026.08e1.1457 1425
        inside 172.16.0.57 0026.b0c0.1e1e 2279
        inside 172.16.0.83 c8bc.c8bf.a6e8 3730
        inside 172.16.0.89 0021.7057.9b7e 6720

After:

router(config)# show arp
        inside 172.16.0.76 0015.afdd.9949 0
        inside 172.16.0.55 0025.64cf.3554 3
        inside 172.16.0.68 0025.004e.4e61 4
        inside 172.16.0.6 0030.4df4.e06c 14
        inside 172.16.0.14 000c.29b4.9cba 21
        inside 172.16.0.10 000c.2953.bbae 22
        inside 172.16.0.7 0030.4df4.e05d 22
        inside 172.16.0.66 0024.e80c.9677 25
        inside 172.16.0.52 0026.08e1.1457 41
        inside 172.16.0.69 0015.c583.6b69 44
        inside 172.16.0.20 000c.2997.7ef9 44
        inside 172.16.0.88 0011.24bf.7e14 44
        outside xxx.xxx.xxx.xxx d0d0.fd47.9ed4 44

bobismighty · ‎01-12-2011

The fix was turning off proxyarp on the inside interface. Now the ASA doesn't screw with the arp tables.

jgraafmans · ‎01-12-2011

Your config is far from a best practice to accomplice what you want and can lead to a lot of strange problems if you configure more things on the ASA especially related to NAT.

You could better turn proxyarp back on and use this setup:

Make sure traffic from 172.16.0.0 to 172.16.1.0 is not being translated by using nonat:

access-list nonat permit ip 172.16.0.0 255.255.255.0 172.16.1.0 255.255.255.0

nat (inside) 0 access-list nonat

Make sure you have same-security-traffic permit intra-interface configured to allow packets coming in on the inside interface to go out to the same interface.

If you configure it this way you can remove following commands:

global (inside) 1 interface
static (inside,inside) 172.16.0.0 172.16.0.0 netmask 255.255.255.0
static (inside,inside) 172.16.1.0 172.16.1.0 netmask 255.255.255.0

access-list acl_inside extended permit ip 172.16.1.0 255.255.255.0 172.16.0.0 255.255.255.0

bobismighty · ‎01-13-2011

Well, I know the current setup is kind of jury rigged, but I'm happy that it's at least functional (for now).

I thought I had tried something similar to what you suggested, but I'll try it again. Unfortunately, all this has to be done after hours, so when I get a chance to do it I'll let you know.

Thanks for the help.

jgraafmans · ‎01-13-2011

If you can upload the full config I can post you the exact commands to make this setup work because without the total config it is hard to tell if there are other commands preventing this setup from working.

Nagaraja Thanthry · ‎01-13-2011

Hello,

I am not sure what code version you are running. If you are running 8.2 and beyond, you have an easier fix. In 8.2 and beyond, there is a feature called as TCP State Bypass that will ensure that all your TCP traffic goes through without any issues in assymmetric routing scenario. So, if you are able to upgrade the code to 8.2 and beyond, here is the configuration you can try:

access-list TCP_bypass permit 172.16.0.0 255.255.255.0 172.16.1.0 255.255.255.0

class-map TCP_bypass

match access-list TCP_bypass

exit

policy-map inside_policy

class TCP_bypass

set connection advanced-options tcp-state-bypass

exit

service-policy inside_policy interface inside

If you are not able to upgrade the code to 8.2, then you need to configure interface NAT:

same-security-traffic permit intra-interface

access-list nonat permit ip 172.16.1.0 255.255.255.0 172.16.0.0 255.255.255.0

nat (inside) 0 access-list nonat

global (inside) 1 interface

nat (inside) 1 172.16.0.0 255.255.255.0

Please make sure that you have removed all other previously configured static NAT statements and NAT 0 statements before trying the above configuation.

Hope this helps.

Regards,

NT