took a while to detect what's was going on, as all other statements just worked fine, except this udp sip entry.
applying this PAT entry wil not result directly in a nonfunctioning IPSEC/NTP/ip sla, but for sure after a reload, IPSEC never will work, neither other services. it looks like it needs some time, (or perhaps triggered by my internal SIP phone)
for IPSEC you can use the ugly workaround by changing as mentioned the IPSEC port, and just "overrule" this behavior with another PAT entry.
I choose for now to reuse the old PAT statement, as i can live for now with it, but i wouln't keep this information by myself, and perhaps it shall be fixed.
Well actually i'm realy curious, if someone can confirm this behaviour?
't took me some time, as i did only discover the issue after a reload, and further testing learned it was also earlier te detect.
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...