We have dynamic NAT configured from inside to outside interface, but still it is showing NAT entry as below.
"NAT from inside:22.214.171.124 to outside:126.96.36.199 flags Ii"
Expected NAT entry should as below :
"NAT from inside:188.8.131.52 to outside:184.108.40.206 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.
What is the impact of disabling xlate in FWSM 4.0.8
The xlate bypass and uRPF check features are unrelated but are often both used to workaround the problem of invalid xlates being built by the FWSM.
The xlate bypass command will simply prevent the FWSM from building identity xlates (i.e. the first xlate you referenced) for all traffic that doesn't match a NAT rule. There shouldn't be an impact on traffic if you enable this feature and it will help reduce your xlate count if you are close to the max limit.
Reverse path verification will not allow the FWSM to build a connection if the source of the packet is not reachable via the interface the packet was received on. As far as xlates go, this would only be useful if the FWSM was building incorrect xlates due to traffic received on a wrong interface (the larger cause of which is a routing problem elsewhere in the network). It does, however, add benefit for security reasons if your routing table is built properly.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...