topic Hello Sir, in Network Security

Switching from PIX to ASA, having issue with additional public subnets

jgrover1108 — Tue, 12 Mar 2019 07:47:14 GMT

I tried switching from a PIX 515-E to an ASA 5515-X over the weekend and while initially it seemed promising ultimately I had to go back to the PIX.

For the sake of sanitization, we'll say that with my ISP I have the following IP address space assigned to us:

172.16.126.32/27 <-- the first block we were assigned.

172.17.50.120/30 <-- subsequent assignment A

172.18.96.216/29 <-- subsequent assignment B

172.19.131.224/28 <-- subsequent assignment C

The ISP's upstream router has the first useable IP in all of the above blocks assigned to our VLAN interface on their equipment. On our PIX we had 172.16.126.34 assigned to its outside interface and its default outside route pointed to 172.16.126.33. Then for all of our other public IP needs--regardless of what block they were in--just having the nat (inside,outside) statement was all that was needed. For instance, we have a server in the DMZ that uses that /30 above. In the PIX config I have nat (DMZ,outside) static 172.17.50.122 10.251.30.5 netmask 255.255.255.255 and the server is able to get online fine. I don't have anything in the config showing that 172.17.50.121 is assigned or routed anywhere; it just worked. Whether this is by design or by luck, I don't know, and I only bring that up in case it's part of the problem I had when I made the switch.

When I first put the new ASA in I used the same information: the outside interface on the ASA had 172.16.126.34 and the default route was pointed to 172.16.126.33. I immediately was able to ping out. I started testing my inbound access list and was able to see things in my DMZ that I'd opened up, and things started looking good. I did notice one host's ports couldn't be reached from outside (one in the 172.18.96.216/29 range) but since it was a lab server I wasn't really worried about it at that moment. I decided to go back to my desk and finish going line by line through my access-list and making sure everything worked.

Unfortunately what I found was that none of my other subnets were working. Anything that was in the 172.16.126.32/27 subnet worked fine, but I couldn't access any hosts in the other subnets, and they couldn't get online, either. I was wondering if it may have been some routing/ARP caching issue on the ISP's upstream router, so as a test I tried changing the outside interface IP to an unused IP in another block (172.19.131.238) and was suddenly able to get to hosts in that range, and they were able to get online themselves. I changed the default IP back to 172.16.126.34 and the 172.19.131.224/28 subnet continued to work, so I thought maybe I was on to something. However after a minute or two my outbound pings from those hosts to the internet stopped working, as did inbound pings/port access. If I repeated the above steps they'd start working again, but they'd always stop working after a couple of minutes.

Any ideas what could cause this? Is it something that would have resolved itself on its own? I'm really hoping I don't have to create subinterfaces on the ASA or something, each with an IP in the above subnets. I don't know if there's just some command that makes things like this work or if it's something known ("Yeah, the PIX used to let you do stuff like that but the ASA won't" sort of thing). I'm working on a sanitized config to upload with this.

**EDIT** Added config.

Hello Sir,

Kornelia Gutierrez — Wed, 25 May 2016 17:58:03 GMT

Hello Sir,

Kindly please enable the arp permit non-connected command and that should do the trick.

ciscoasa(config)# arp permit-nonconnected

The ASA by default from asa code 8.4.5 does not answer arp requests for subnets that are not direcly connected to the box (this means that if you do not have an interface configured in the ASA within the range 172.17.x.x or 172.18.x.x, he will reject both incoming arp requests and responses), the command mentioned above overwrites that behavior and allows the connectivity for the subnets that are not directly connected, on the pix and older code like 8.0,8.2 you do not see the problem and do not have the need to enable this command since the feauture is already enabled within the code, it is integraded, but after 8.4 the feature is turned off by default.

Please refer to the following docs for more information:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/A-H/cmdref1/a3.html#pgfId-1837762

https://supportforums.cisco.com/discussion/11848306/arp-permit-nonconnected

Hope this helps!

I was really hoping this

jgrover1108 — Thu, 26 May 2016 14:01:05 GMT

I was really hoping this would work, but apparently it didn't.

HQ-ASA-FW# config t
HQ-ASA-FW(config)# arp permit-nonconnected
^
ERROR: % Invalid input detected at '^' marker.

After looking around online I found another discussion here: https://supportforums.cisco.com/discussion/11797666/asa-86-allow-publishing-only-one-range-public-ip

The correct answer indicates that the arp permit-nonconnected command is not available in 8.5(1), 8.6(1) or 8.7(1). My ASA is 8.6(1).

It appears that I'll need to have the ISP change these to routed blocks pointed at our external interface (as I'd rather not go to an older software version on the device).

Thanks for pointing me in the right direction.