I'm working through an issue with MX64 as a client VPN server behind a 3rd party (Fortigate) firewall. I have UDP/4500 and UDP/500 forwarded from the WAN interface of the other firewall to the MX64. I've looked at packet captures and can see the following:
1) SA completes (client to server ephemeral port 57234 to 500)
2) KE completes (ephemeral port 57234 to 500)
3) ID - client sends ID on ephemeral ports 35121 to 4500, but MX replies with source port 4500 to destination 4500 - i.e. it doesn't reply with dst port 35121 - that the session is established on - so it gets dropped.
I ran a test with another MX NATted behind another firewall, and this worked fine. The difference was at step 3) - this MX replied from 4500 back to the ephemeral DST port (42854 in this case), then established the connection and proceeded to ESP.
My question is, in the first non-working scenario, why is the MX64 replying from 4500->4500 instead of 4500->35121? I can't fund any reason why it's not behaving in the same way as the working example.
Thanks PhilipDAth. By the remote device do you mean the client/initiator as oppose to the server? If yes this is the weird part - it’s exactly the same device and the behaviour is different based on which server setup that it connects to.
You mention that you tested with another MX NATed behind another device. Is that other device also a Fortigate firewall? It’s possible that the Fortigate is detecting the L2TP/IPSec and trying to be ‘smart’ with its NAT and actually introducing a problem. I would see if there is ‘smart’/application processing on the Fortigate that you can turn-off and just let NAT be NAT.