MX64 as a one-arm mode VPN concentrator, dual WAN, and manual port forward

[RJordan-CCS]

We have an MX64 intended to act as a VPN concentrator behind a NAT mode Sonicwall NSA2600.  We cannot get the MX to accept it as VPN friendly so autoVPN is not working (this was also tested behind an older Sonicwall TZ215 and worked, so maybe something in the newer Sonicwalls changed).  So we may need to switch from automatic NAT to manual port forward.

Still trying different things to get the MX happy but it provides no details about what the specific problem is (sorry Meraki but this is a far too common issue), and the Sonicwall packet traces are not showing the symptoms described in the troubleshooting doc (port changes, packet drops, etc).  There are no rules that would impede outbound traffic from the MX64's IP address or subnet, and no inbound blocking rules that would apply.  The NAT policies are similarly unencumbered by restrictions.  In fact the LAN and NAT setup looks almost like the working TZ215 testbed, except for one inbound public server on port 8088 TCP/UDP.  Which of course I can't turn off.

Is there any way to get the site to site VPN manual port forwarding setup to work with a dual WAN setup on the upstream Sonicwall, set in failover mode?  We need the tunnels to come up regardless of which of the two ISP connections is in use but there is only an entry field for one IP and port.

Thanks for any info.

[PhilipDAth]

Here is the documentation about unfriendly NAT:

https://documentation.meraki.com/MX/Site-to-site_VPN/Troubleshooting_VPN_Registration_for_Meraki_Aut...

Basically the MX needs to make an out going UDP connection - and have return traffic able to come back on that port.  Common issues with upstream firewalls are them closing the dyanmic PAT after a set time or having no idle timers.

If your upstream firewall has dual Internet connections and you are load balancing you will have massive issues, as this breaks the above premise immediately.  If you can, configure the upstream to force all of the MX traffic onto one circuit and use the other circuit only for failover.

[RJordan-CCS]

Philip

     the site is not load balancing; it is failover only with preemptive fallback to the primary circuit when it is restored.  They understand that the tunnels will go down for potentially several minutes during such an event but want them to come back up automatically, without manual intervention if the primary WAN link fails (as the main Sonicwall tunnels would to their remote fixed IP sites).

     As a test we set up a 1:1 NAT on the NSA2600 from an available public IP to the MX LAN IP.  Still kept getting unfriendly NAT but the test tunnel from a Z1 teleworker came up with both ends set to autoVPN.  Of course setting up the 1:1 NAT tied the setup to the primary WAN (their secondary only has the one public IP address available in any case so we can't set up 1:1 for it).

     After working with phone support (who could not determine why we were still getting the NAT unfriendly warning after several packet capture analyses) we're staying with this setup; a failover will be tested when the customer can handle the likely downtime.  We tried setting a temporary hard route on the NSA2600 for the MX to use the secondary WAN exclusively; it stayed showing unfriendly NAT and the tunnels would not start. 

     So far as we can tell, you cannot set up site to site VPN using manual port forwarding to work with dual WANs with failover; you can enter only one public IP address.  Switching would be a manual operation via the dashboard, or using the API if that particular action is supported (I have not looked).

     I never thought about the UDP timeouts.  The default on the Sonicwall is 30 seconds; I don't see any docs that indicate that changes with a 1:1 NAT configuration.  However we can increase the timeout substantially; I think this firewall/firmware can support up to 3600 seconds.  We'll give that a try.

Thanks for responding

Rich