Teleworker VPN after MX84 move

AshMead
Getting noticed

Teleworker VPN after MX84 move

I have an SSID configured as a Teleworker VPN. It connects to an MX84 configured as a one armed VPN concentrator.

 

I have moved the MX84 into our data centre and onto a new subnet. The SSID is now not advertised.

 

I suspect that the tunnel needs re-building to the MX84 in it's new network location. How do I make this happen? 

 

Many thanks

11 Replies 11
ww
Kind of a big deal
Kind of a big deal

Reboot your AP?

AshMead
Getting noticed

Hi

 

Thanks but unfortunately the reboot did not work. The SSID is still not visible. btw it's an MR45 on 25.14.

 

Any other ideas? I'm thinking I need to call support

ww
Kind of a big deal
Kind of a big deal

If you moved the DC subnet/IP. is the new iP allowed to communicate (in case its behind a fw) on all ports listed (at Help> firewall Info) in your dashboard?

PhilipDAth
Kind of a big deal
Kind of a big deal

Does the MX84 show it is registered with the VPN registry correctly?

@PhilipDAth How do I check this please?

 

cmr
Kind of a big deal
Kind of a big deal

MR45 and 25.14 isn't a good combination, I'd try 26.7 (I have an MR55 on it), you can always roll back for the next few days (5-7 I think).

PhilipDAth
Kind of a big deal
Kind of a big deal

You can check the VPN registry status in:

Security & SD-WAN/VPN Status

 

CN
Meraki Alumni (Retired)
Meraki Alumni (Retired)

In teleworker, if the SSID isn't broadcasting then the VPN tunnel to the MX has not formed. Instead of relying on a random chance for the port number assignment, I would recommend setting it statically. If you go to Security & SD-WAN > Wireless Concentrator on the MX you're concentrating to, then you can define a NAT traversal of Manual: Port forwarding where you manually input the public IP and port. Now at the edge firewall create a port forward, pointing all traffic on the UDP port you specified to the IP of the MX. 

 

What I think is happening is that somewhere along the path, port numbers are getting changed and firewalls are blocking the traffic. By creating the port forward you reduce the chance of traffic getting blocked if there is no corresponding outbound flow. 

 

This recommendation isn't just for Teleworker VPN. I highly recommend this be done for EVERY hub in auto VPN. The spokes are harder to control and likely using templates, so I don't bother. But the hubs, it's a very simple change that reaps the most benefits. 

 

Even if you decide to not do the port forward it's still worth it. By setting the manual port you are telling the MX to use that port all the time. If you don't have it, and the MX rebooted the port would change. Not only would all of the VPN tunnels all have to reform, but all of the UDP sessions would need to be rebuilt from scratch. By keeping the same port we can reduce the load. 

 

In summary, I would make sure that the AP can form the VPN tunnel to the MX. Use manual port forwarding so that you can make sure that the traffic can get into your datacenter. 

AshMead
Getting noticed

Wow, thanks. I’ll give this a try on Monday. I’ll update the post with results!

AshMead
Getting noticed

When re-booting the AP I notice that I get 

 

VPN registry connectivity change vpn_type: teleworker, vap: 5, connectivity: true

 

 

but I do not get a VPN tunnel connectivity change

Does this mean that the VPN tries to form but the tunnel is not completed?

 

Also will the APs try to form the tunnel to the Public or local IP address? 

CN
Meraki Alumni (Retired)
Meraki Alumni (Retired)

The AP will try and reach both the Public and local IP of the MX. On the AP's wired interface you could do a packet capture and look for connection attempts to the MX. Is there two communication? 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels