ASA 8.2 Global Outside works, but static NAT mappings fail

[max]

Hello,

I'm usually not stumped by issues, but this one I cannot seem to figure out.

I have an older Pix and I've mirrored the config on a new ASA with 8.2(5) OS. It's a pretty basic config with one ACL for a few inbound port forwards to servers. The service is Verizon Fios Business.

When we switch over from the old Pix to the new ASA connectivity through global outside statment work fine. Workstations on the LAN can connect outbound to websites, etc.

However, none of the servers using static NAT mappings work inbound or outbound. And there are 4 servers, and we've tested them all for various issues. The static mappings are done using the static statement as such "static (inside,outside) exchange 10.0.2.7 netmask 255.255.255.255" and not using a network object. I have other installs with this same exact OS version that work fine with the static statement, so I'm not sure that this has anything to do with it. I'll add that these 4 servers also have inbound ports forwarded via one ACL, which also do NOT work.

When we switch it back to the Pix unit with same config, all the servers on static NAT work just fine immediately.

Can anyone give any insite on what the problem might be based on what I've described? I've checked and checked the configs and see no issues. And I've done may ASA configuration/installs, but I would say I'm moderately new to 8.x(x), although as I said above I have others in production working fine with static NAT mappings.

Thanks for any assistance,

Max

[Harvey Ortiz]

Hi Max,

As I understand you are replacing a Pix with a new ASA, also that you have well configured the static Nat and the access list.

Once you have pluged the ASA to ISP device, I will recommend to reload the ISP device so it can learn/update the Arp entry for the new ASA.

Please rate if this is the correct answer.

[max]

Thanks Harvey and Vibhor for your responses!

However, yes, we tried recycling the power on the upstream router. This is Verizon Fios Business, and their router was hooked in a more permanent fashion to a battery backup without a way to recycle. But we finally were able to kill the power on it. This definitely seemed like it could be the problem, but there was no difference afterwards.

Thanks,

Max

[Vibhor Amrodia]

Hi,

Did you try the workaround as mentioned in this URL that i provided you before:-

https://supportforums.cisco.com/blog/149276/asapix-proxy-arp-vs-gratuitous-arp

Thanks and Regards,

Vibhor Amrodia

[Vibhor Amrodia]

Hi,

I am guessing that the traffic never reaches the ASA device in the first place. This means that the ASA is not able to ask for the traffic for the Static NAtted IP addresses.

Check this article:-

https://supportforums.cisco.com/blog/149276/asapix-proxy-arp-vs-gratuitous-arp

Either clear the arp on the ISP router or use the other workaround as mentioned on the post.

Thanks and Regards,

Vibhor Amrodia

[max]

Guys,

Another thing that just came to my attention. Verizon Fios wrote down our public subnet mask as being 255.255.255.0 but stated we have only 5 IP addresses available. I'm thinking our mask should be .248, but the new ASA is set for the /24 mask. Is it possible this could cause the issues described above with the new ASA but would have worked with the old Pix? We are trying to confirm with Verizon on the correct mask as well.

Thanks,

Max

[Harvey Ortiz]

Hi Max,

If the mask was configured on the Pix as /24, the configuration should work fine.

The only thing you could do from the ASA will be to setup packet captures, so we can verify that traffic is arriving to the ASA:

capture out interface outside match ip any host PUBLIC-IP

*Then send some traffic to PUBLIC-IP, verify the capture:

show capture out

Regards,

Harvey.

[Marius Gunnerud]

another thing you can do in addition to the packet capture mentioned by Harvey is a packet-tracer which will simulate a packet going through the ASA and could point us in the right direction of where the issue is.

packet-tracer input <interface name> tcp <source IP> <source port> <destination IP> <destination port> detail

I suggest running the packet tracer in both directions (from the servers to the internet, as well as from the internet to the servers).  Keep in mind that when using the packet tracer with a source out on the internet you need to specify the destination as the NATed IP of the servers.  The following link can give you a little more info on the packet tracer

https://supportforums.cisco.com/document/29601/troubleshooting-access-problems-using-packet-tracer

--

Please remember to select a correct answer and rate helpful posts

[max]

Thanks guys, I'm going to try the tracing/capture.

Max

[will]

just a few thoughts:

1. possible need to ensure sysopt for proxy arp is enabled?

2. need to ensure that the NAT statements are in the correct order, with the static

3. almost sounds like some sort of routing or subnet mask issue.

4. trying converting one of the statics from a NAT to some sort of HTTP (unique port) NAT, just NAT-ing port 80 on the static. then see if the server can use the global dynamic as well as have its in place.

5. in this line: (inside,outside) exchange 10.0.2.7

you intended for "exchange" = the outside IP, correct?