Client VPN subnet cannot reach local lan subnet

meraki1976
Here to help

Client VPN subnet cannot reach local lan subnet

I recently configured a client VPN on my MX.  The vpn clients get an address in a 192.168.1.0/24 subnet, meanwhile all the servers and such are on a 192.168.0.1 subnet.  I cannot ping or access in any other way from the client vpn subnet, to the local lan subnet.  I have googled this and searched this forum but nothings seems to apply.  

22 Replies 22
KarstenI
Kind of a big deal
Kind of a big deal

I would start with a packet-capture on the MX to see if the packets are even reaching the MX and are forwarded to the servers.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
meraki1976
Here to help

I do see the icmp requests going on the client vpn interface with no response.

Brash
Kind of a big deal
Kind of a big deal

By default, the Meraki client VPN is a full tunnel with access to all LAN subnets.

 

I suggest checking your L3 firewall rules 

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

 

It's also worth checking the routing table on the client device to confirm that 192.168.0.0/24 is being sent to the client's the VPN interface.

 

 

 

 

meraki1976
Here to help

the firewall rules are permit all for everything. 

 

my servers don't have any static routes on them to point back, however there is no client vpn gateway listed.   I did try using the MX as a gateway but is on the same subnet as the clients.  I figured the client vpn and the mx interface are "directly connected"

Brash
Kind of a big deal
Kind of a big deal

Does the MX have an address configured for the server VLAN?

If not, you'll need to add a static route on the MX to reach the server subnet, and ensure there is a static (or dynamic) route on the server subnet gateway to reach the MX client VPN subnet.

meraki1976
Here to help

My MX has a def gateway set to the ISP's LAN interface.  I am guessing when something comes in from the 192.168.1.0/24 subnet, the MX doesn't realize that the subnet is directly connected, then passes it off to the ISP router, which has no idea how to find 192.168.1.0/24.  Does that make sense?

mljevakovic
Here to help

I'm just wandering if you clients network (home network) is the same subnet like your server net 192.168.0.0/24? If it is it could be a problem.

meraki1976
Here to help

On a packet capture of the lan interface while running a ping, I see arp requests for my destination that says who has 192.168.0.x, please tell the ip address of the MX interface 192.168.0.x.  On a packet cap of the Client VPN interface I see the pings go out and it says, "no response"  .  However when I am not VPN'd with a 192.168.1.x/24) and my PC is on the same interface as the MX and server vlan (192.168.0.x/24), I can ping and reach the esxi host and cimc.  Why is there some sort of arp/reachability problem when I am coming from 192.168.1.x from my VPN?.  Is there any gateway ip address for the Client VPN on the MX that I can't see?

Bruce
Kind of a big deal

What MX firmware are you running? It might be worth checking you’re up to date. (I believe there was a small bug in one of the recent versions).

meraki1976
Here to help

15.43, going to upgrade to 15.44 now

meraki1976
Here to help

no luck

Bruce
Kind of a big deal

Can you show the route table from the client (once the VPN is connected) - what is the shown as the destination for the 192.168.0.0/24 route, and/or the default route 0.0.0.0/0 since its full tunnel. Also, what are the default gateways configured on the CIMC and the ESXi host? And can you cut and paste the route table from the MX.

meraki1976
Here to help

meraki1976_0-1631661048844.png

 

meraki1976
Here to help

for the default gw on the cimc or esxi host I have tried both the ISP router and the MX gateway in the same subnet with the same result

Brash
Kind of a big deal
Kind of a big deal

The gateway for the servers will need to be the MX, unless you have a static route on the ISP router pointing 192.168.1.x/24 towards your MX.

 

Just to confirm, which mode is the MX set up in, and can you confirm the topology with the server subnet, the MX and the ISP router?

 

My next steps would probably be running a packet cap on esxi to determine whether it's the forward or reverse path having the issue.

 

 

meraki1976
Here to help

Cable wasn't plugged in....sorry....thanks, though

GIdenJoe
Kind of a big deal
Kind of a big deal

@mljevakovic 

That is basic routing:

If your client is in the same subnet at home as the subnet behind the VPN the client will locally ARP for the host instead of sending in through the VPN.

 

If you would however use routes with smaller subnets like /32 host routes to the VPN it is possible the client will take these instead but if an actual device on your own subnet at home is also at that exact IP it will locally resolve that address.

Bruce
Kind of a big deal

Check the firewall rules on the Windows server. Depending on the Windows server version you may find they are restricted to allowing connections from the local subnet (i.e. 192.168.0.0/24).

meraki1976
Here to help

I'm pinging ESXI host or CIMC, not Windows installation.  The one subnet is 192.168.0.0/24 and the other is 192.168.1.0/24. sp the client vpn subnet is not on the same subnet as the server vlan.  Yes the MX has an ip address in the server vlan.

PhilipDAth
Kind of a big deal
Kind of a big deal

Check that the servers are configured with a /24 netmask.

meraki1976
Here to help

yes, they are

MukonDerick
New here

Have you found a solution to this problem? 

I'm having the same issue. 
I have a client VPN subnet 172.20.246.0/24 and a local Subnet 192.168.1.0/24 with local resources that I need to access from both sides 172.20.246.0/24 needs access to 192.168.1.0/24 and vice versa. 

MukonDerick_0-1663052696693.png

 

MukonDerick_1-1663052879775.png

 

When I try and reach 172.20.246.0/24 subnet from a server on 192.168.1.2 it tries to route out via the ISP and nopt over the VPN tunnel. Seems as if I need a static route 

 

Get notified when there are additional replies to this discussion.