NON MERAKI IPSEC TUNNEL

[palakshah]

As discussed on our call it looks like there may be an issue with the upstream NAT device infront of MX85 interfering with the connection. Please ensure this device is allowing traffic fully between the two destinations and carry out packet captures on the WAN of both MXs simultaneously while trying to send traffic across the tunnel to see whats happening on a packet level. 

[alemabrahao]

The non-Meraki VPN tunnel works without issues behind NAT (I've used it myself at home). However, as you mentioned, you need to check if the device in front of Meraki (I believe it's the ISP's router) allows this.

If you don't have access to the router, I recommend contacting your ISP.

[alemabrahao]

Packet Capture Steps
Navigate to:

Network-wide > Packet Capture
Select MX Appliance and choose WAN Interface.

Configure Capture:

Protocol: Select UDP and ESP (or Any if unsure).
Host IPs: Enter the public IPs of both MX devices.
Port: Use 500 and 4500 (for IPsec/NAT-T).
Duration: Set for 60–120 seconds during active traffic.

Start Capture on both MXs simultaneously.

Initiate Traffic:

Send pings or data across the VPN tunnel during the capture window.

Download PCAP Files from both devices.

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overvi...

[GIdenJoe]

IPsec VPN's use UDP/500 and UDP/4500 (when behind NAT) to do the IKE exchange.
When the negotiation is done data traffic is sent inside UDP/4500.

Things to check if a NAT exists at one or both of the sides in front of the VPN device is that first.
Does incoming UDP/500 or 4500 is getting through to the MX appliance?  You can check this by running packet captures.

If traffic gets through both ways you can still have an issue with the IKE identifier that has to be modified.  Usually you will see that the negotiation fails in phase 1 at the authentication exchange.