Double xlate entries inside to outside and outside to outside

[David Williams]

We had a situation where we would get two xlate entries on an FWSM for the same public IP resulting in occasional looping of traffic.  For example:

static nat entry for <private IP B on inside interface> to <public IP A on outside interface>

xlate entries would be created for inside:B to outside:A

However we would also see entries for outside:A to outside:A.

Sometimes this would cause traffic to loop back to the gateway of the FWSM and sometimes it would pass it through.  When we would clear the xlate table traffic would start passing again.  Sometimes for hours sometimes for minutes and then it would happen again.  I understand that xlate is looked at before routes so this makes sense.  What I don't understand, is if there are two xlate entries, which does it choose to use to translate the traffic?

The fix seems to have been to remove the same-security-traffic permit intra-interface command.  I understand what this command does as well, what I don't understand about this is what conditions would have created the outside to outside xlate.

Any thoughts?

[Panos Kampanakis]

If you have the "same-security" command and you see a packet hitting the outside interface sourced from x destined to y, if the routing table says that y is behind the outside then the firewall will hair-pin the traffic on the outside interface and will create an identity translation for outside: x to outside: x.

That is probably your cause.

I hope it makes sense.

PK

[bagga_ajeet]

same-security-traffic permit intra-interface simply allows traffic to hairpin the interface, and disabling it disallows it. The buggy dynamic NAT is created when the FWSM sees the src IP in the header as the same as the xlate'd-to-IP. A logical equivalent of a IP verify (unicast) reverse path will cause the spoofed (or misconfigured) src to get dropped at the interesting interface. Just be careful instituting it on the ASA as you might have purposeful cases of sources choosing a firewall gateway when sourcing, where as the ASA might route to the destination down a different interface. Same word of caution when disabling hairpins.

[David Williams]

So this was most likely this case of some yahoo spoofing their src IP and sending traffic to an IP that is routed at the FWSM, or spoofing their source to match the destination IP.  By implementing IP verify (unicast) reverse path the spoofed packet would get dropped before creating an xlate in the first place preventing the FWSM from exhibiting the odd routing from ever happening.

So is it a fair statement that IF implementing same-security-traffic permit intra-interface that you would at least want to implement ip verify reverse-path on the public facing interface as well?

So my last question then is when there are two xlates present in the xlate table, the legitimate inside to outside and then the bogus outside to outside, what logic does the FWSM use to pick which xlate entry to use?

Thanks for the explanation!  This is good stuff. 

[Panos Kampanakis]

If you have 2 xlates it is longest match first for the FWSM and then if the mask is the same it is the priority in the xlate table.

Yes rpf check would help because you shouldn't see traffic on your outside sourced from an ip that you supposedly own and translate on the firewall.

I hope it makes sense.

PK

[size57]

Hi,

We have dynamic NAT configured from inside to outside interface, but still it

is showing NAT entry as below.

"NAT from inside:177.26.99.10 to outside:177.26.99.10 flags Ii"

Expected NAT entry should as below :

"NAT from inside:177.26.99.10 to outside:111.111.111.111 flags Ii"

Can you please explain this behaviour, and suggest if xlate-bypass can help

here. We were considering implementing "ip verify revert-path" .Hence here i

am thinking whether xlate-bypass is the issue here and implementing same

with "ip verify revert-path" woud be a good idea.