ASA not responding for Public Address

Unanswered Question
Jun 26th, 2009

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.



Attachment: 
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
kcaskey Fri, 06/26/2009 - 07:52

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...

kwillacey Fri, 06/26/2009 - 08:11

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.

kcaskey Fri, 06/26/2009 - 08:32

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?

kwillacey Fri, 06/26/2009 - 09:24

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.

kwillacey Mon, 06/29/2009 - 10:50

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.

kwillacey Mon, 07/06/2009 - 14:57

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.

Jon Marshall Mon, 07/06/2009 - 15:08

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

Kureli Sankar Mon, 07/06/2009 - 18:38

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.



Jon Marshall Tue, 07/07/2009 - 02:10

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

kwillacey Tue, 07/07/2009 - 05:52

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.


Kureli Sankar Tue, 07/07/2009 - 06:41

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.



kwillacey Mon, 07/13/2009 - 11:53

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

kwillacey Tue, 07/14/2009 - 09:05

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.

Actions

This Discussion