cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1653
Views
0
Helpful
15
Replies

ASA not responding for Public Address

kwillacey
Level 3
Level 3

I have an ASA 5505 that will not respond to a second public address that was acquired. However this address is within a different subnet.

(not actual public addresses)

Interface IP: 10.10.2.2

New IP: 10.10.5.2

Translations using the Interface IP work with no problems but translations with the new IP does not. The hit count on the outside access-list, that refers to the entry with the new IP, does not increase it stays at 0 as if no traffic is reaching the ASA.

(not actual public addresses)

Interface IP: 10.10.5.2

Old IP: 10.10.2.2

If I swap around the addresses and place the new IP on the interface the translations work but those to the old IP don't. The same thing happens here for the access-list.

As anyone ever had this issue? It should also be noted that this ASA is replacing a checkpoint and the checkpoint has no issue translating for both addresses.

Configuration is attached.

15 Replies 15

kcaskey
Level 1
Level 1

Explain "respond"? Are these inbound or outbound flows you are hoping to achieve?

In quickly glancing at the config, I don't believe your NAT rules are setup correctly...

My static NAT rules are correct.

static (inside,outside) tcp interface www 10.10.1.35 www netmask 255.255.255.255

static (inside,outside) tcp interface 65100 10.10.1.35 65100 netmask 255.255.255.255

static (inside,outside) tcp interface ftp-data 10.10.1.9 ftp-data netmask 255.255.255.255

static (inside,outside) tcp interface ftp 10.10.1.9 ftp netmask 255.255.255.255

The translations above do work, users from the Internet can browse to the web server and perform ftp requests.

static (inside,outside) 10.10.5.2 10.10.1.34 netmask 255.255.255.255

The translation above which uses the new IP that is not on the interface, and is not in the same subnet as the one on the interface, does not work. I am guessing it is because it is in a different subent from the one that is currently on the interface. I know for sure it would work if both addresses were in the same subnet.

If it were a router I know I could add a secondary addresses and the router would respond and perform the translation even though the address would be in a different subent.

Okay, I think I'm understanding the issue a little better now.

Have you tried traffic in both directions or only inbound (such as the Internet web surfing and FTP you gave as test examples on the working NAT)?

I should probably ask - is there a routing device on the outside of this firewall or does the outside interface live directly on the Internet?

Outbound traffic works without any problems even after I change the interface IP address.

There is no routing device in front of the firewall it connects directly to the Internet.

My thinking is the ASA is not responding to ARP requests for the new address because it's not in the same subnet as the one that is on the interface.

Is there anyway to get this to work because it works on the checkpoint this ASA is suppose to replace with no problems.

Any thoughts anyone? Any experts that can help?

I really think that this is an ARP issue and given that I would like to try the following, can anyone tell me if it would work or have an opinion.

Adding a static ARP entry for the new public IP address, to allow the ASA to respond to ARP requests.

int vlan 2

mac-address xxxx.xxxx.xxxx (obtainded from show int e0/0)

ip address 10.10.2.2 255.255.255.252

arp outside 10.10.5.2 xxxx.xxxx.xxxx alias

static (inside,outside) 10.10.5.2 10.10.1.34 netmask 255.255.255.255

Any help or thoughts would be greatly appreciated.

I did the following on the ASA but got no where. I was still unable to access the web server on 10.10.5.2, however I am still only able to reach the web server that translates to the IP address on the vlan 2 interface 10.10.2.2

int vlan 2

mac-address 0018.199e.bd19

ip address 10.10.2.2 255.255.255.252

arp outside 10.10.5.2 0018.199e.bd19 alias

static (inside,outside) 10.10.5.2 10.10.1.34 netmask 255.255.255.255

static (inside,outside) tcp interface www 10.10.1.35 www netmask 255.255.255.255

access-list outside_access_in extended permit tcp any host 10.10.2.2 eq www

access-list outside_access_in extended permit tcp any host 10.10.5.2 eq www

access-list outside_access_in extended permit tcp any host 10.10.5.2 eq 800

Thinking the ASA is the problem I put in a router and had the same luck, even when I added the other IP as a secondary, I was only able to access the web server on 10.10.2.2 and not the one on 10.10.5.2.

int f0/0

ip address 10.10.5.2 255.255.255.252 secondary

ip address 10.10.2.2 255.255.255.252

ip nat outside

int f0/1

ip address 10.10.1.40 255.255.255.0

ip nat inside

ip nat inside source static tcp 10.10.1.35 www int f0/0 www

ip nat inside source static tcp 10.10.1.34 www 10.10.5.2 www

And of course it works on the checkpoint with no problems so I am out of ideas, Please any thoughts or suggestions and I mean ANY would be helpful at this point. I have never had a problem with such a simple static translation.

Kelvin

Is the second IP address routed to your ASA by your ISP ? So if someone tried to connect to the new address from the Internet would they end up at the outside interface of your firewall ?

The ASA should have no problem doing what you are trying to do as long as you have not disabled proxy-arp on the outside interface of the ASA ?

Have you looked in the xlate table ?

Jon

If the ISP didn't route that new IP address to the ASA it would work when this IP address is assigned to the interface.

I do not see any sysopt commands in the config.

The best thing to do will be as follows.

1. sh xlate debug | i 10.10.1.34

2. cap capout int outside match ip host 10.10.5.2 any

generate some traffic from 10.10.1.34

3. issue sh cap capout

and see if there are any response packets arriving to 10.10.5.2.

4. issue "sh cap capout detail" and make sure the source and destination mac address shows up correct.

If you see packets leaving with the source IP of 10.10.5.2 but, none with the destination IP of 10.10.5.2 then, pls. contact your ISP.

Kureli

"If the ISP didn't route that new IP address to the ASA it would work when this IP address is assigned to the interface."

Agreed but that is what is confusing. The new IP address is from a different subnet. So if you apply the new IP address to the outside interface then the next-hop address ie. the ISP router, is now in a different subnet ie. the old subnet. So at the moment it's unclear how that would work because the ASA would look up the next-hop and see that it is in a different subnet to it's outside interface.

So i just wanted to clarify what is actually happening.

Jon

Thanks for your input John and Kureli, I have not tried connecting to the firewall on that address I just made an assumption that they are routing that address to the firewall since it works on the checkpoint. Proxy arp is not disabled and figuring it was an arp problem I entered a static arp entry but that did not work. There are no hits on the outside acl and nothing in the xlate table for that IP address, even when I change the logging level to debugging I see no connections coming in to that IP address.

The weird thing is if I place the new IP address on the interface it works fine but translations to the old IP no longer does. Kureli as you said does this mean that the IP address is not being routed to the firewall? I will give what you suggested a try and if I do not achieve the desired results I will get the ISP involved, thanks.

Jon,

"If the ISP didn't route that new IP address to the ASA it would work when this IP address is assigned to the interface."

I should have said wouldn't instead of would.

You got a good point about being diff. subnet. We do not know what IP addresses the ISP interface has (may be it has a secondary address assigned) who knows. We don't have a "show run int " output to verify.

Capture will be our best friend in this case.

Wish me luck I'm gonna try another swap today and do some packet capture.

This appears to be an ISP issue based on the packet capture on the ASA and the sniffing I did with wireshark. Will update when they figure out the issue.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card