I do not know RFC by heart (as you already pointed out :-)), but what I see is that 2800 is the responder, and we never recieive MM5 which shoule be the first packet with UDP/4500 (this is common on all Cisco devices, I have never seen any debugs indiacting otherwise). That being said we don't see vpn3k info at all, so hard to say for cerrtain what's going on.
I doubt it's a PAT device on the way - it would also cause UDP/500 to get dropped. (depends of course on how the PAT is done).
With limited info we have I'm sticking to my analysis.
I have been looking at this and this is a strange setup, I will try and explain as best I can.
What we have is a VPN between the 2800 and the VPN3k, if the VPN3k initiated the VPN this works fine. The problem seems to be when this is initiated from the 2800, there are othe VPN's peers (2) on the 2800 that work fine.
so here is the setup: 2800-------ASA-1-------ASA-2------PIX-----VPN3k
When traffic gets to ASA-1 there is no NAT control but a VPN tunnel to ASA-2, then this ASA-2 has a static translation to the outside interface.
I was thinking maybe the problem is on ASA-2, we are allowing ISAKMP, ESP, UDP4500 to the static address of the 2800.
static (inside,outside) <2800 ip addr> netmask 255.255.255.255
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...