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?
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
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?
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).
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.
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?
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?