MR autovpn creation with concentrator (L3 roaoming or vpn tunnel)

[DerekH]

I have an MX in vpn concentrator mode at our hub and an MX, MS (switch) and MR (AP) at a spoke site. The spoke has dual links, one via the internet and one via the internal network. The spoke MX is up and working via autovpn into the hub MX over both links, and the MS and MR on the LAN of the spoke have Meraki cloud connectivity via the central MX internet connectivity path.

I've bought up a new ssid at the spoke and am trying to test connectivity to the MX in the datacentre (via the Test connectivity button under addressing and traffic on the MR) and I can see in our firewall logs that the MR is trying to establish an auto-vpn tunnel to the external NAT IP of the hub MX, which of course is failing as you would need to go externally and come back in via the hub internet to match that NAT entry. I know that the MRs are probably built to be used independently of MR/MX infrastructure, but I thought that the MR would have tried to build the autovpn tunnel via the internal internal as well ie internal IP of the MR and internal IP of the hub MX.

Is there anyway to configure the AP to build the autovpn from the MR to the MX at the hub via the internal network. I've tried both Layer 3 roaming with a concentrator and VPN: tunnel data to a concentrator as options on the ssid but I have the same issue with both. I know that I could probably put the MR on an internet facing vlan at the spoke and then it would build the auto-vpn tunnel over the internet back into the hub MX and work because it would match the NAT, but then I lose redundancy should the internet link at the spoke fail.

[ww]

I dont know the answer. But cant you  use bridge  mode  ssid , instead of building  the ssidtunnel over mxtunnel.

[PhilipDAth]

Why does the MR need to use the VPN concentrator?  It sounds like you have full IP connectivity back to the DC already.

Otherwise you are going to need the MR management IP to access the Internet via the same public IP address as your VPN concentrator.  If they use the same public IP address when talking to the cloud they will attempt to build a connection between themselves using AutoVPN.

[DerekH]

I have a number of ssids with local offload (ie bridged mode with a vlan tag) either for direct internet access ie guest or standard internal corp access within the SDWAN. I have one ssid which needs to be carried back to the DC for special treatment and this is what I am checking to see if it works.

The MR and MX concentrator in the DC uses the same public IP address to talk to the cloud, they both match the same outgoing nat rule on our central firewall. Is it just that the "test connectivity" function on the ssid only tries to establish the tunnel with the NAT ip of the DC controller, whereas if I just configure L3 Roaming on the spoke MR to the hub MX and save the config, then the MR would try the additional paths and establish the MR autovpn tunnel via the internal ip address? Are there any issues with having the auto-vpn tunnel for the MR establish over the existing MX/MX autovpn tunnel ie mtu issues that can happen with tunnel in tunnel?

[PhilipDAth]

In that case, the MR should be trying to connect to the private IP address on the MX concentrator.  MR uses the same rules as AutoVPN to build the tunnels.

I would open a support case.