Hi All,
A company has two sites, a head office and a branch office.
Both offices have MX65 Meraki and Site-to-Site VPN configured as shown on the screenshots.
HO:
BO:
The VPN configuration on both devices makes absolutely no sense for me but nevertheless I can ping BO devices from the HO and vice versa.
Also, the real public IP address (which I replaced with 14.14.14.14) doesn't belong neither to the HO nor the BO and specified on both Meraki devices.
Please advise how it is possible.
Solved! Go to solution.
The first part is the meraki autovpn. A hub connects a hub so your mx will form the vpn tunnels automatically
The last part is for non meraki vpn tunnels. So both mx build a tunnel to (most likely) a non meraki device.
https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#Non-Meraki_VPN_Peers
The first part is the meraki autovpn. A hub connects a hub so your mx will form the vpn tunnels automatically
The last part is for non meraki vpn tunnels. So both mx build a tunnel to (most likely) a non meraki device.
https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#Non-Meraki_VPN_Peers
Hi @ww
I've just check another Meraki router for another organization and the setup became a bit clearer.
(Still not clear though where both routers are connected to.)
Another question is if a Meraki router can establish VPN if it is behind NAT?
Yes, most NATed networks don't cause an issue, even CGNAT from mobile networks often work. It can however affect the ability for client VPN users to connect to the MX. If the particular NAT the MX is behind is causing problems, an alert saying unfriendly NAT will appear in the dashboard.
AutoVPN works as follows.
Each autovpn peer will try to reach two Meraki VPN registries.
It announches it's own WAN IP and port it is using inside fields in packets going upstream
So when a NAT exists between the MX and the registry the packet L3 and L4 header will be altered by having the public IP and port. So the VPN registry knows what the private WAN IP and port is AND the public side. This data gets forwarded to all the peers so they can attempt to form their VPN tunnels directly by using hole punching through the NAT.
This can of course fail if there is an upstream router/firewall only allowing specific ports outbound. In that case you have to manually select an UDP port and fill in your public IP. That way all peers will attempt connection through that IP and port.