I am having problem with VPN setup for overlapping network scenario on PIX 525 running 6.3(4) OS with unrestricted licence. I tried to use first PAT then standard static translation to hide the 192.168... network on vpn initiating network. With continous ping running I can see hits incrementing on all relevant access lists (including crypto map access-list) but debug crypto isakmp output shows nothing for this particular vpn but displays output when other vpns get built. I checked all obvious things like ping getting to inside interface and via inside in access-list, routing, nat 0, access-list for other vpns (to see if traffic gets routed down other tunnels) but no joy.
Yes, the crypto access list includes NATed address as a source and remote end is configured correctly.
I can see hit count on both NAT and crypto access list incrementing with continuos ping running from a host behind "vpn initiator" peer (PIX 525).
My problem is that there is no output from "debug crypto isakmp" command for this vpn (output is displayed for other 20 vpns on this PIX???), so I assume that no isakmp packets for phase 1 are generated by vpn initiating PIX (I can see no packets when running "debug packet outside dst both" command.
The "show xlate | include 188.8.131.52" command output shows my local to global mapping correctly, so NAT seems to work. I can see hit count on crypto map access list increasing with every ping packet coming, so (I think):
1) routing sends PATed packet to outside interface (otherwise crypto map "relevant traffic" access-list would not come into play).
2) crypto map should pick up the "request" to bring up vpn, but no isakmp packets are generated.
I had 10 years of mainframe (Tandem) experience and I have never before seen mainframe debug failing to generate output.
It is difficult to fault find if key tool does not show anything ;-(
I even changed the config to use static (inside, outside) etc translation, but again there is no output from debug although xlate and crypto map access-list behave correctly.
are there any known gotchas with either PIX 6.3(4) routing or PATing which would result in this behaviour?
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...