I'm experiencing an issue that I've been able to replicate on standard user accounts and admin accounts, on multiple devices. I have two separate networks (meaning it's a two hour car ride from one to the other) both running Meraki MX64 routers that talk to each other, one's the hub, the other a spoke. As long as I am physically at either office I can access everything on the network fine, including RDP'ing (windows 10 computers, virtual machines running anything from Server 2010 to 2019) to virtual machines, accessing a file server, and a few physical devices like two security camera boxes.
The problem I'm running into is when I connect to the office via VPN (Meraki's VPN service), which we run from our hub router, we can't RDP or access anything running out of our spoke's router. I get the same "make sure you typed in the address correctly" error as though I'd entered a bad address.
I am out of ideas on what to even try at this point, and whatever my problem is the language is so vague that google searches find everything except my specific problem. It's not a permissions issue because even top level admin accounts can't access it, VPN is allowed on both networks, this works normally when I do it from the hub's network when I'm in the office, the only difference is that I'm connecting to the office via a VPN remotely instead of the office's network directly.
Solved! Go to Solution.
When you say VPN is allowed on both networks, are you talking about Client VPN or Site-to-Site VPN?
You have to enable S2S VPN access for the client VPN subnets, same as you do for VLANs.
VPN is allowed on both networks, Site-to-site VPN is active, every VLAN that would have network devices we are trying to connect to is allowing it, client VPN's are active on both networks, and I allowed the relevant user accounts in client VPN to connect to either network.
All of this works normally, as intended when you're on the hub or spoke's network directly, and you can access anything you're allowed to access on either network. The problem only comes up when someone connects to the network remotely via VPN and then tried to connect or access something on the other network. Specifically I am trying to connect to the hub's network via VPN from home, and then access a device on the spoke's network.
Is your hub in routed mode or concentrator mode? And, on the site to site VPN page do you have the client VPN subnet enabled for VPN? Could be the spoke is using split tunnel and traffic back to the VPN client via the hub isn't being advertised and so it's going directly out the spoke's internet link?
I bet it will be the second point @Ryan_Miles made - the client VPN subnet won't be enabled for use in AutoVPN.
I know this bit inside out - and I still get caught out. I start with a functioning network with AutoVPN already built, enable client VPN, and then forget to go back into the Site to Site VPN settings page and enable the client VPN subnet for use in AutoVPN.
I'm hoping to stop making this mistake soon.
The hub is set to 'routed' mode, not 'passthrough or VPN concentrator.' The spoke is also set to 'routed.'
Does the spoke's VPN config page matter? Because every VLAN we're trying to access has VPN turned on. Again, we're running our VPN out of our hub, not the spoke. The VLAN for VPN connections is on the hub.
As for the hub's VPN config page, VPN is enabled for all VLAN's that we need access to, but the specific VLAN set aside for the client VPN has it disabled? I'm guessing that specifically refers to VPN access to objects located on that specific VLAN?
Could be the spoke is using split tunnel and traffic back to the VNP client via the hub isn't being advertised so it's going directly out the spoke's internet link?
I have no idea. I know that the spoke's router connects to it's switch from one port, and then has a single internet connection, but for whatever reason it's not plugged into the designated 'internet' port.
That ended up being the solution. I'm waiting for an end user to confirm it works for them but my own testing demonstrated that it worked.
I thought that setting was granting VPN users access to those given subnets so for security reasons I didn't want people with VPN access to be able to meddle with the VPN VLAN.