Client VPN for Access to Network Drives

[Steve_M]

My company just ported to a new ISP which uses a Meraki MX67.

I have a server which is a domain controller with active directory, a DHCP server, and which contains network drives. With my previous ISP, I used a SonicWall and had a VPN for my remote users to access the network drives. Once the VPN was connected I could "add a network location" as if I was on site.

I have not been able to configure a Client VPN in the MX67 to work in the same way. I got as far as having a remote computer connect to the Meraki Client VPN using the Meraki Cloud Authentication, but I can't get the network drives connected.

Any input on how I can get this configured would be much appreciated.

[alemabrahao]

What version are you running? Are you using L2TP or Anyconnect? Do you have any L3 rules that could be causing this?

[Steve_M]

Version MX 16.16, using L2TP.

There are no custom rules defined in L3.

[alemabrahao · Accepted solution]

Are your machines configured on a domain? Are you trying to access it by name or IP? If you run a tracert where does your traffic stop? Can you ping the MX LAN IP?

[Steve_M]

We have a domain, but I'm using IP addresses. 

I ran a tracert on the MX public IP and took 4 hops to reach it, and it stops after the 5th hop after reaching the IP twice.

[alemabrahao]

No to the public IP, try to perform a tracert over VPN to MX local LAN IP.

[Steve_M]

My drives are on the 192.16.24.0/24 subnet, and the MX IP is 192.16.24.1. 

I did a tracert to 192.16.24.1 from a computer currently using the Client VPN. Please see below.

[alemabrahao]

Well, you're getting to the MX's IP, so the problem is probably the server's response. Do you have any L3 switches in the middle?

[Steve_M]

Yes, I have a 48-port TP-Link switch.

[Steve_M]

I did some tests and the Meraki won't let me access network drives that are not in the same subnet, even if they are connected to the same switch. I guess whatever is causing this is also preventing VPN clients from accessing the network as well. Do you have any idea of why this is happening?

[alemabrahao]

Does your switch have any L3 interface and route pointing to MX? It looks like a routing issue. Can you share your Switch and MX configurations (like interfaces, routes, etc)?

[Steve_M]

Right now I have my server and another computer plugged directly into the MX using different ports. If I place them in the same VLAN I can access the network drives, but if they are in different VLANs I lose access. My guess is whatever is causing this is also giving me trouble with the Client VPNs.

[alemabrahao]

Is this server windows server? Have you tried disabling the firewall on both the server and the client workstation?

[Steve_M]

Yes to both questions.

[Steve_M]

Typing the server IP (instead of the name) to access the network drive worked. The server name only works within the same subnet.

[BlakeRichardson]

You will need to create rules allowing traffic from the VPN subnet to your local subnet. 

[alemabrahao]

@BlakeRichardson, but all the traffic is allowed unless you have a rule to block It.

[BlakeRichardson]

@alemabrahao It's been ages since I used client VPN on an MX but I am sure I had to add in rules allowing traffic from VPN to Local LAN. If I am wrong or thats changed thats incredibly insecure as a default setting. 

[alemabrahao]

unless they changed it I'm sure no rules are needed. I tested it in my Lab environment and it was unnecessary to create any rules.

[alemabrahao]

@BlakeRichardson 

https://documentation.meraki.com/MX/Client_VPN/Restricting_Client_VPN_access_using_Layer_3_firewall_...

Restricting Client VPN access using Layer 3 firewall rules

Client VPN users may access all subnets within the network by default. In order to control or restrict access for Client VPN users, firewall rules should be implemented.

Layer 3 firewall rules are a powerful tool for permitting and denying Client VPN traffic. Although Client VPN users are considered part of the LAN, network administrators may see a need for limiting overall access. Firewall rules can be used to limit access for VPN users to specific addresses/ports or ranges of addresses. Such as allowing access to most information, but denying access to sensitive resources to VPN users.

[Steve_M]

The VPN subnet is 192.168.1.0/24 and the network drive is located on 192.16.24.10.

I created the rule below, but it didn't help.

[JessIT1]

We are having similar issues, users connect to VPN but can't access shared drive back on HQ network..never been an issue before..user having issue is running windows 11, looking to see if windows 10 users are having same issue..

[alemabrahao]

I just tested It here and It worked well.

[JessIT1]

so getting feedback from my users, anyone that did not do fresh VPN connection attempt in last 2 hours or so is still connected to VPN fine and can access the shared drive on our network. Any new connections get connected very briefly then dropped. Some get an error, some don't. Has to be an ongoing issue with Meraki MX firewalls since issue just started in last few hours.

[alemabrahao]

have you not reached the maximum number of available addresses? What range did you configure for the Client VPN?

[JessIT1]

No, not reached maximum addresses. Don't think client IP range is applicable here. Issue is this afternoon users can't make new connections to VPN, we use radius server for authentication.

[alemabrahao]

Well, none of my customers have reported any issues and Meraki has not made any official announcements. You are using a native Windows Client VPN, so it could be that Microsoft has released an update that is affecting systems as it has in the past.

[jedimaster]

Same thing happening here.  I discovered that the user was shutting down laptop while still connected to the VPN session.  I asked the user to disconnect from the VPN before shutting down the laptop to see if that formal VPN termination fixes the issue.  I am not sure why the Meraki client VPN service would keep alive a session for that long without activity, though.

[PhilipDAth]

Is the client VPN configuration giving out the AD controller IP address for the DNS server?

The most common issue I run into regarding these kinds of problems are Windows Firewall.  Perhaps the change in firewall has triggered Windows firewall to change the location it is in.

On the machine you are trying to access the mapped drive on (and the AD controller) - try disabling Windows Firewall and then see if VPN clients can access it.

[Steve_M]

I disabled the firewall but it didn't help. I did some tests and the Meraki won't let me access network drives that are not in the same subnet, even if they are connected to the same switch. I guess whatever is causing this is also preventing VPN clients from accessing the network as well. Do you have any idea of why this is happening?

[JessIT1]

So an update, I sometimes add IOC IP addresses that are C2 to our Meraki Content Filtering  / URL Filtering block list.

I was testing VPN connection from home last night and got an error from http://wired.meraki.com:8090 blockng IP address - 13.107.4.52

I checked my URL list and saw that IP had been added by me earlier in the day, I removed it and bingo VPN connection stayed connected. Virus Total has mixed reviews on this IP, see below. Cisco Umbrella Investigate shows safe as well.

https://www.virustotal.com/gui/url/20991264dd712bc59c82126e951fb8f22a9cec3021a4f08f62da4e925db29f86