Thanks Philip   That explains everything clearly and my tests prove that you're right.   Cheers Mat ... View more

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 ... View more

Hi Philipp I have done further tests and I still can generate IP address overlaps. Just to make sure that I understand the concept of overlap checking in Meraki: Are the checks made per network bound to the same template (in which I define the uniqueness) or are the checks made based on the entire organization (all networks bound to a template and the ones that are not bound to a template)? Thanks for reading and supporting people. Mat ... View more

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 ... View more

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 ... View more

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  ... View more

Hi Philipp even though in some configuration situations I received error messages about overlapping IP subnets and I was not able to proceed I was able to configure my network in a way to have overlapping IP subnets. This was the case when I added a spoke site that used the pool of IP subnets out of the template. I do not know why the tests work when trying to add a hub site with overlapping IP addresses but not in the case where a spoke site gets an IP address out of the pool. So I think that the best strategy is still to use non-overlapping address spaces for hub and spokes, but that was clear in the first place. Thanks for taking the time for replying my (silly) questions. Matthias   ... View more

If the MX is the DHCP server the incomplete ARP is not likely to be the issue since the traffic is routed and ARP is only necessary for the default gateway IP address in the local VLAN. It looks to me as if something in the DHCP processing on the client side as gone wrong. Did you do an ipconfig /all (or whatever the OS of the client might need to display the IP config) to see if the DNS servers and the Default Gateway were present in the PC?  If everything is/was ok, could/can you ping the DNS server? Are you able to able to ping devices in proximity to the DNS server? ... View more

Thanks for the reply! ... View more

Hi jdsilva   Thanks for your reply and sorry for my late reply. That's indeed the way to go, L2TPv3 Tunnels or EoGRE would be others but due to technical restrictions I'll continue with your idea.   Cheers mat ... View more