Multiple MX in different organizations

[mat1458]

Hi

I want to have multiple MX of different organizations in a data center that hide behind a non-Meraki firewall. All MX are in the same subnet. The MX act as VPN concentrators for SSID tunnels to APs of multiple customers. If I have a look at the documentation on how the tunnels are invoked (https://documentation.meraki.com/MX/Site-to-site_VPN/Automatic_NAT_Traversal_for_IPsec_Tunneling_bet...) I see in the example that the SF-MX selects a UDP port for the tunnel source/destination dynamically. Is there a way to make sure that these ports do not overlap when I hide all data center MX behind the same IP address to the internet? Or in other words: what is the algorithm for an MX to choose a UDP port for VPNs?

Any ideas are welcome.

Cheers 

Mat

[BrechtSchamp]

I suppose both MX's use a private address on their WAN end and NAT-ing occurs on the non-Meraki firewall. At that point I expect the NAT-step will translate the randomly chosen port to another randomly chosen port. The non-Meraki firewall will make sure it doesn't use the same port twice for translation. So I expect that you wouldn't experience issues there.

Alternatively you could setup manual NAT-traversal in the site-to-site settings of the MX's, in both MX's you'll probably have the same public IP (your non-Meraki firewall's public IP) so naturally you'll need to use two different ports. And then of course you'll need to actually setup that port forwarding in your firewall. Mind you, I haven't tested if the MR's tunnels would also respect that configuration, but I would expect they will.

[mat1458]

Hi Brecht

Thanks for your reply. But if I understand you correctly, the non-Meraki FW would change the port in your scenario. How can the Meraki VPN registry track the different outside port? In my opinion there is no direct relationship between the FW and the registry. So some messaging (error messages?) could be used for this update but I don't see any way, how to do this update.

In my opinion it could only work, if the VPN registry remarks the duplicate port numbers before it announces them and urges one of the data center MXs to change it's source port and then re-announce it. Or Meraki relies on coincidence with the random function on the port range.

Cheers

Mat 

[BrechtSchamp]

Basically the VPN registry detects which port was chosen by the non-Meraki firewall when it receives the connection. So in other words, the blue arrow originates from the MX, goes through the non-Meraki firewall and arrives at the VPN registry. So the registry only sees the actual chosen port by the non-Meraki firewall. More or less the same thing happens with the IP-address, the registry registers the public IP address of the non-Meraki firewall, not the actual WAN-address of the MX (unless there's no NAT and it has its own public IP, but then this whole hole-punching technique becomes irrelevant anyway). 

[PhilipDAth]

@BrechtSchamp has done an excellent job answering the question.

The only other thing I could add is that it is possible to use a static port for AutoVPN.  I've needed to do this in the past when the outside firewall would expire the NAT translation causing all the AutoVPN tunnels to go down until the new NAT port gets registered.  If you use a static port and you port forward this by the outside firewall then this case can never happen.

https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-site_VPN_Settings#NAT_Traversal

[mat1458]

Hi Brecht

Thanks for the answer and sorry for the delay. I still have a question. The way I understand PAT (NAPT) it always consists of a two tuples: one describing local SrcIP/SrcPort and the corresponding global SrcIP/SrcPort, the other one describing local DstIP/DstPort and the corresponding global DstIP/DstPort.

Now for the MX1 this would be something like local IP10.1.1.1/UDP40001 and global IP1.2.3.4/UDP40001 to local 64.62.142.12/UDP9350 and global 64.62.142.12/UDP9350. This in my opinion punches a hole for the connection between the two endpoint IP addresses. When having a second MX2 behind the same ISP firewall the situation would look like that: IP10.1.1.2/UDP40001 and global IP1.2.3.4/UDP40002 to local 64.62.142.12/UDP9350 and global 64.62.142.12/UDP9350. The UDP port for both MXs differs on the outside, but in my opinion only for the communication to 64.62.142.12/UDP9350.

When assuming that an access point tries to set up a connection to MX2 it sends a UDP packet to IP1.2.3.4/UDP40002. Since the public IP address of the access point is not known the packet is dropped at MX2's ISP FW. Now if the MX2 tries to open the communication to the AP: is there a rule for the ISP FW to use the same UDP port number (40002) to the different public IP address of the access point? Or is it just the way most of the NAPT devices work?

Sorry to bother you again but maybe you can help me understand the process more profoundly.

Kind regards

Mat

[BrechtSchamp · Accepted solution]

Hey Mat,

You should check the "Figure 3. Connection phase: Peers use UDP hole punching to establish an IPsec tunnel." part in the link you posted in your opening post:

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

Basically you're right, when the AP first tries to make the connection it will get blocked by the firewall. But thanks to that try it will have punched the hole in the firewall on the AP side. Meanwhile, the MX also tries to make an outgoing connection to the AP. It too, at this point, will punch a hole, this time in the firewall on the MX side. Both holes have now been punched and the connection can be established.

It doesn't always work though. See this concentrator deployment guide for more info:

https://documentation.meraki.com/MX/Deployment_Guides/VPN_Concentrator_Deployment_Guide

Use manual NAT traversal when:

• There is an unfriendly NAT upstream
• Stringent firewall rules are in place to control what traffic is allowed to ingress or egress the datacenter
• It is important to know which port remote sites will use to communicate with the VPN concentrator

There's also this link to troubleshoot packet streams:

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

[mat1458]

Thanks Brecht for all the time you dedicate to my issue. The way I see it there must be a mechanism in the ISP FW NAPT process that re-uses previously assigned source ports for different IP addresses in the outgoing direction (which makes sense from an economical assignment point of view). This way the hole punching basically opens the same port on the public side for all outgoing UDP connections from the same inside source address.

That way the whole model can work.

Kind regards and many thanks again.

Mat

[BrechtSchamp]

Yeah, a well-behaving NAT should use the same port for all outgoing connections originating from a source tuple that it already chose a port for.

The referenced white-paper goes through everything in great detail and is an interesting read too:

http://bford.info/pub/net/p2pnat.pdf

Specifically section 3.4 describes the process I also described.

[mat1458]

I did not yet know about the well-behaved part of the FW. But looking at it it makes a lot of sense in terms of economizing ports.

Thanks for your endurance in answering my questions.

Mat