static nat that not belong to the outside interface subnet

mathieuploton · ‎02-21-2011

Dear all,

I have created static nat entries on my firewall. The problem is that those ips does not belong to the outside interface subnet.

My device is not cisco so i cannot really paste a configuration that makes sense but i think it is more a network principle or feature i am looking for.

I have this situation :

Internet router --- Firewall -- Lan

Let say my firewall outside interface is :

interface Ethernet0/2

nameif outside

security-level 100

ip address 202.14.18.91 255.255.255.240

And i have this entry :

static (inside,outside) 202.14.18.113 192.168.150.233 netmask 255.255.255.255

This public ip does not belong to the outside interface subnet.

On the internet router, to make it work, i add a static route :

ip route 202.14.18.113 255.255.255.255 202.14.18.91

But when I try to ping 202.14.18.113 form outside, I get TTL expired in transit.

Which is actually normal as in my firewall, if i do sh route outside 202.14.18.113, it is pointing me to my internet gateway. So it is looping between the two hops.

I have to say, my nat works fine for inside to outside so basically there is no issue here. I am just wondering what is the impact of such a loop as I am seeing a lot of TTL exceeded on the statistics due to this situation and how to fix this.

Hope this makes sense....

Maykol Rojas · ‎02-21-2011

Hi,

I think I understand, but It makes sense in a way....

If you tell the firewall, where is the network 202.14.18.0? of course he does not have a clue. If he checks on his routing table, the closest would be the default gateway. Then the packet gets to the router and the router is going to sent the packet back to the ASA.... I dont see a problem with that and it would generate a loop

Now, the ASA wont need to generate packets with a destination address of 202.14.18.113. So, When the router sends a packet destined to 202.14.18.113, the ASA will unstranslate the packet and sent it out to 192.168.150.233 and the reply is going to be translated to 202.14.18.113 and so on.

The loop would be originated only if the ASA is trying to send a packet destined to 202.14.18.113....which, in any case, I dont see why would you do something like that.

Mike

mathieuploton · ‎02-21-2011

I don't see either but around 13% of my input traffic is TTL exceeded from remote hosts over the internet trying to ping my public nat ips. I dont know if those are attacks or just a normal mecanism I am not thinking of (maybe PMTU ?)

mathieuploton · ‎02-22-2011

Any idea ?

Maykol Rojas · ‎02-22-2011

Can you catch one of this logs, packets and poste it over here?

Let me know.

Mike

mathieuploton · ‎02-22-2011

This is the debug packet icmp from the firewall :

I anonymised the private ips and public nat pool.

Nat pool is 201.143.121.148-152

*4.2603201849 TangoFW1 IP/8/debug_icmp:

ICMP Send: ttl-exceeded(Type=11, Code=0), Src = 10.32.4.202, Dst = 202.170.115.102; Original IP header: Pro = 17, Src = 202.170.115.102, Dst = 201.143.121.152, First 8 bytes = D337BF25 007214FE

*4.2603201849 TangoFW1 IP/8/debug_icmp:

ICMP Send: ttl-exceeded(Type=11, Code=0), Src = 10.32.4.202, Dst = 59.113.152.46; Original IP header: Pro = 6, Src = 59.113.152.46, Dst = 201.143.121.148, First 8 bytes = 01BBD1D0 48544224

*4.2603201849 TangoFW1 IP/8/debug_icmp:

ICMP Send: ttl-exceeded(Type=11, Code=0), Src = 10.32.4.202, Dst = 121.116.132.20; Original IP header: Pro = 6, Src = 121.116.132.20, Dst = 201.143.121.148, First 8 bytes = 01BB6D91 3E583EEE

*4.2603201949 TangoFW1 IP/8/debug_icmp:

ICMP Send: ttl-exceeded(Type=11, Code=0), Src = 10.32.4.202, Dst = 213.146.189.202; Original IP header: Pro = 6, Src = 213.146.189.202, Dst = 201.143.121.150, First 8 bytes = 0050E52A 86447771

*4.2603201949 TangoFW1 IP/8/debug_icmp:

ICMP Send: ttl-exceeded(Type=11, Code=0), Src = 10.32.4.202, Dst = 201.143.121.148; Original IP header: Pro = 6, Src = 201.143.121.148, Dst = 201.143.121.152, First 8 bytes = D239E84B 4ABBD73C

*4.2603201949 TangoFW1 IP/8/debug_icmp:

ICMP Send: ttl-exceeded(Type=11, Code=0), Src = 10.32.4.202, Dst = 96.17.8.50; Original IP header: Pro = 6, Src = 96.17.8.50, Dst = 201.143.121.148, First 8 bytes = 00509F2A E7D44042

*4.2603202049 TangoFW1 IP/8/debug_icmp:

ICMP Send: ttl-exceeded(Type=11, Code=0), Src = 10.32.4.202, Dst = 60.52.24.139; Original IP header: Pro = 17, Src = 60.52.24.139, Dst = 201.143.121.151, First 8 bytes = 2EB3707A 006D2382

*4.2603202049 TangoFW1 IP/8/debug_icmp:

ICMP Send: ttl-exceeded(Type=11, Code=0), Src = 10.32.4.202, Dst = 213.146.189.203; Original IP header: Pro = 6, Src = 213.146.189.203, Dst = 201.143.121.150, First 8 bytes = 01BBE2FF 8600ADE3

undo terminal debugging

*4.2603202149 TangoFW1 IP/8/debug_icmp:

ICMP Send: ttl-exceeded(Type=11, Code=0), Src = 10.32.4.202, Dst = 213.146.189.201; Original IP header: Pro = 6, Src = 213.146.189.201, Dst = 201.143.121.150, First 8 bytes = 303ECC09 8516F9BE

*4.2603202266 TangoFW1 IP/8/debug_icmp:

ICMP Send: ttl-exceeded(Type=11, Code=0), Src = 10.32.4.202, Dst = 182.52.196.135; Original IP header: Pro = 17, Src = 182.52.196.135, Dst = 201.143.121.149, First 8 bytes = 4985254C 0026616D

mathieuploton · ‎02-23-2011

Problem solved by support, they suggest to blackhole the route to the nat pool.