Meraki Client VPN Issues

[PaulCoad]

New position, new to Meraki....

We have our client VPN setup, it works fine, but...

I can ping from the client on the VPN to any network resource, but can't ping from a server to a client that is on the VPN. The VPN is setup and open, what am I missing, I looked around and could see nothing out of place.

[PhilipDAth]

My guess  - Windows firewall on the client machine.

My second guess - An antivirus firewall on the client machine.

[PaulCoad]

Tried that turned all those features off on a few laptops to test and still nothing. 

[daniel_bostock]

Paul,

Just to be clear, can you confirm please if the server in question is on the VPN subnet or another subnet?

Thanks,

Daniel.

[Nash]

@PaulCoad 

okay, end user connects to client VPN successfully, then can’t access the server?

Couple things:

1. What is your server’s subnet and what’s the remote network’s subnet? Do they overlap? Home networks are commonly 192.168.1.0/24 or 192.168.0.0/24.

2. What’s the subnet on the client vpn? I usually pick something like 172.28.200.0/24. Reduces the risk of overlap.

If you have overlapping subnets, you’re going to have trouble communicating. Change subnets so they’re all three unique.

[DanielQueiroz]

I have a similar problem! The VPN client (Windows 10) successfully connects and receives IP 192.168.100.97 from subnet 192.168.100.0/24, but this VPN client does not ping devices from the Corporate network from subnet 192.168.20.0/24, but the reverse works.

192.168.100.97 (VPN) -> 192.168.20.0/24 (CORP) - NOK PING
192.168.100.97 (VPN) -> 192.168.20.1 (CORP) - OK PING
192.168.20.0/24 (CORP) -> 192.168.100.97 (VPN) - OK PING

The VPN client (192.168.100.97) can only reach the gateway 192.168.20.1 (CORP).

I already disabled Windows firewall and VPN client antivirus.

Do I need to configure any routes? I can not identify the fault.

[daniel_bostock]

@DanielQueiroz -

Can you please confirm if your MX is managing the corporate network as well, IE: Does 192.168.20.1 IP address exist on the MX or another network device?

Also if you can please let me know if you have specific Firewall rules configured on your MX to control inbound and outbound access.

This will help me to get a clearer picture of how packets will move from your vpn subnet to your corporate subnet.

With regards to the the reverse working, this is an indicator that there is not a routing issue but most likely a firewall issue or something similar that is seeing this traffic destined for this subnet and doing something to control it. If there was no connectivity you would not be able to reach from the corporate network. So, you are getting that far at least and good job, almost there now!

Thanks,.

Thanks,

Daniel.

[JainD21]

If you are able to ping the gateway from the spoke subnet, it means both subnets participated in Auto VPN. Need to check if any firewall or anything placed in LAN or off the windows firewall and try again.

[BrechtSchamp]

@PaulCoad 

If it's not a firewall issue (which was the most likely). It could also be a NAT step at some point in the chain. Check with traceroute/tracert what route the ping takes, whether that is the expected route and if there's NATing in it.

@DanielQueiroz Not sure what you're saying here, you're saying ping to 20.1 works, but to 20.0/24 doesn't. 20.1 is a part of 20.0/24...

[PaulCoad]

This is the same problem I have.

[PaulCoad]

PPP adapter Prospira:

Here is the IP I'm given when connecting to the VPN.  

 Connection-specific DNS Suffix  . :

   Description . . . . . . . . . . . : Prospira

   Physical Address. . . . . . . . . :

   DHCP Enabled. . . . . . . . . . . : No

   Autoconfiguration Enabled . . . . : Yes

   IPv4 Address. . . . . . . . . . . : 10.12.99.53(Preferred)

   Subnet Mask . . . . . . . . . . . : 255.255.255.255

   Default Gateway . . . . . . . . . : 0.0.0.0

   DNS Servers . . . . . . . . . . . : 10.12.61.78

                                       10.12.61.79

   NetBIOS over Tcpip. . . . . . . . : Enabled

IP info of server:

Ethernet adapter Ethernet0:

   Connection-specific DNS Suffix  . :

   Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter

   Physical Address. . . . . . . . . : 00-50-56-96-4C-68

   DHCP Enabled. . . . . . . . . . . : Yes

   Autoconfiguration Enabled . . . . : Yes

   IPv4 Address. . . . . . . . . . . : 10.12.61.218(Preferred)

   Subnet Mask . . . . . . . . . . . : 255.255.255.0

   Lease Obtained. . . . . . . . . . : Friday, November 1, 2019 12:26:42 PM

   Lease Expires . . . . . . . . . . : Tuesday, December 24, 2019 10:59:11 PM

   Default Gateway . . . . . . . . . : 10.12.61.1

   DHCP Server . . . . . . . . . . . : 10.12.61.1

   DNS Servers . . . . . . . . . . . : 10.12.61.78

                                       10.12.61.79

   NetBIOS over Tcpip. . . . . . . . : Enabled

If I tracert my computer name from the server, it hits the FW 10.12.61.1 and that's it, times out after that. 

I agree that this is either a NAT or a FW Rule issue. 

[daniel_bostock]

@PaulCoad 

I believe it is an issue with your VPN configuration of the adapter on your computer since you have DHCP disabled.

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Prospira
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.12.99.53(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 0.0.0.0
DNS Servers . . . . . . . . . . . : 10.12.61.78
10.12.61.79
NetBIOS over Tcpip. . . . . . . . : Enabled

1. Your subnet is a /32 subnet.

2. You have no default gateway.

The reasons why this problematic.

1. With a host subnet (/32) subnet it effectively means it thinks it the only device in it's own little network. If your VPN network is a /24 network, then you should see a subnet that matches 255.255.255.0 . Which if you look at your servers interface that is what is configured for it's subnet. This type of configuration on your adapter for the subnet is what we call a host /32 subnet. It is typically configured on loopbacks used for management or monitoring, it shouldn't be used in this scenario. You will just need to review your manual adapter configuration and either set to DHCP or configure an ip address and subnet mask that reflects the VPN network.

2. No default gateway means your computer does not know an entry or exit point to the rest of the world effectively. It has no gateway. This also is configured manually on your network adapter or also received via DHCP. You can manually put in your gateway here, such as the VPN network interface configured on the Meraki MX - 10.12.99.1

Let me know how you go with this Paul and I hope this gets you going!

Thanks.

[DanielQueiroz]

@daniel_bostock 
@JainD21 
@BrechtSchamp 

Hello guys! IP 192.168.20.1 is on MX and there are no specific Firewall rules configured on MX.

As you reinforced to check the firewall rules in Windows, today I revised the rules again and discovered the problem.

The client that was on the Corporate network (192.168.20.65), was running a kaspersky antivirus and was blocking ICMP and RDP, we made the antivirus adjustments on packet rules and now everything is working as expected.

@PaulCoad 

I hope you can solve it too!

Guys, thank you for your help!

[PaulCoad]

Update: Able to ping a VPN client by IP from a server, but DNS is not updating with client side IP, Meraki says I need to use a Wins server for that?

[Nash]

Oh no no, please do NOT install WINS. Microsoft explicitly says not to unless you've got, e.g., a Windows XP machine kicking around that needs it.

Do you have a local DNS server? What's your local domain?

If you have a local DNS server, try using the fully qualified domain name, such as server.domain.local. In my example, "domain.local" is the domain name.

[PaulCoad]

The Meraki VPN is not updating the Windows Server 2016 DNS, what am I missing?

[Nash]

On the client VPN page, do you have your DNS servers set like below? Change the IP addresses to the internal IP of your DNS server, of course.

[PaulCoad]

Yes and the DNS does not update with the VPN IP. To test, I have manually changed the DNS records to their perspective IP's and then things are working. 

[PaulCoad]

Just got off the phone with Meraki and yet again, this is there fix.

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

I was told that the Meraki client VPN hasn't seen an update in years and this is why you will have to use a Wins server if you want your servers to be able to resolve NetBIOS names over the VPN.

[PhilipDAth]

>I was told that the Meraki client VPN hasn't seen an update in years 

There is no "Meraki VPN Client".  There is only the Microsoft VPN client, which is built into Windows.

If you have local AD controllers on-site you should be able to use those.  NetBIOS is not required in this case.  One issue I have seen in the past is the zones by default only allowing secure updates, and sometimes when machines attach to the network they attempt to update their names prior to machine authentication, causing the update to fail.

Sometimes I just disable secure updates on the DNS zones in AD to resolve this.  The issue they create with not being able to update is more severe then the security posture lost.