Client IPSec vpn setup and working, but cannot access Resources on a Vlan with a public IP subnet.

[RCMikesell]

This is a Meraki MX replacing another brand of firewall.

Client has chosen to use the IPSec VPN on the firewall, not wanting to pay for AnyConnect so that option is unfortunately out.

 - edit: attempted with AnyConnect as well... same issue.

VPN is configured with Radius Authentication and DUO mfa

It is operating using the Windows VPN and is operating as expected to connect to the site.

The problem I fear is the client, far in the painful past, chose to use a Private IP subnet for their LAN Vlan.

Config:

VLAN 1 is setup as in the 100.0.1.0/24 subnet

IPsec VPN is setup with the Private IP subnet 192.168.18.0/24

Layer 3 Rules allow access from the VPN subnet to VLAN 1 

Layer 3 Rules allow for any source and destination ports

Ipsec is currently setup to forward all traffic over the VPN to the client site (confirmed with show my ip when connected)

Pings to the local DNS server do not return from VPN client, but do from MX Tests

Client Tracert results show Tracing route to lo0-100.BSTNMA-VFTTP-350.verizon-gni.net [100.0.1.1]

Firewall reports and packet captuers show that the Firewall is receiving the packets and that  Layer 3 rules are allowing the VPN to access through to 100.0.1.1

Based on this information I believe the MX is routing the traffic destined for the 100.0.1.0/24 subnet to the internet

I cannot enter a static route to point to the firewall VLAN ip for the Subnet as it already exists in its routing table

Any ideas out there on if there is a way to make this work, the previous VPN on the old firewall allowed for it to work

[RCMikesell]

Some notes on your suggestion:

• LAN and VPN do not share overlapping subnet address spaces
  • VPN is on 192.168.18.0/24 (also attempted with 192.168.200.0/24)
  • LAN is on 100.0.1.0/24
• Would love to re-segment the VLAN, but as its already in production and not my company, likely not a possibility.
  • If I was initially rebuilding the entire network, this would be the solution, but not in this case.
• VPN Subnet Translation is a Site to Site protocol only, not Client to Site (which is the issue here)
  • This is a good thought, but as its exclusive to site to site, doesn't work in this case
• I did try setup of a Route Add for the host to point to the Vpn for specific IP subnets
  • This made no difference as the routes on the host already push all traffic to the Meraki (this is default setup and requires changes on the Host interface to split traffic)
  • Enabling the VPN writes a host route of 0.0.0.0 to catch all, and is set at a significantly lower metric so it takes precedence. 

[rhbirkelund]

What does the route table on the MX say for 100.0.1.0/24 ?

[RCMikesell]

The host routing and internally is:

• Ver	Subnet	Nam	VLAN	NextHop	Destina	Type
  4	100.0.1.0/24	LAN	1	100.0.1.2	100.0.1.2	Local VLAN

• 100.0.1.2 is the interface IP on VLAN1 in the meraki

[rhbirkelund]

If there's an entry for 100.0.1.0/24 in the route table, then I'd argue the MX should adhere to that. Since it's a local VLAN traffic shouldn't be forwarded to Internet. 

What does the route table on the windows host sat, when connected to VPN?

[RCMikesell]

This was from back when I was trying the 192.168.200.0/24 network for the VPN:

the 192.168.4.147 is my local IP and the first routing rule but its metric is fairly high compared to the added route pointing to the IPsec interface (at this time) of 192.168.200.155 with its metric of 26. 

[rhbirkelund]

If you trace route from the windows host towards a ressource on 100.0.1.0/24, what do you get?

[RCMikesell]

When attempting to access 100.0.1.1 using windows based tracert:

Tracing route to lo0-100.BSTNMA-VFTTP-350.verizon-gni.net [100.0.1.1]

Comparison:

Off VPN:

to On VPN:

[RCMikesell]

Also to note, I did do a packet capture on the Meraki itself testing if the packets were arriving at the Meraki and getting through.   I was able to see them arriving.

[rhbirkelund]

If you see packets arriving at the MX from a cap, I'd argue that traffic is getting routed towards the MX. However, since 100.0.1.0/24 is a Local VLAN I think it should take precedence over the default route. 

I do see that both trace routes seem to resolve the address as one of Verizons.

[RCMikesell]

Agreed on packets getting to the MX, but then its going to the WAN rather than the VLAN.  This is what has me questioning if the default routing for non RFC1918 addresses to a WAN connection is taking precedence over the Internal address list on the VLAN.  The routing table shows no metrics.

[rhbirkelund · Accepted solution]

The MX Routing Behaviour states that Directly Connected routes should take precedence.

https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior

And since 100.0.1.0/24 is a local vlan, the MX should choose that over the default route. 

I think you should open a case with Meraki ,and have them verify.

[RCMikesell]

Opened a Ticket with Meraki. 

[RCMikesell]

Your link leads to a list of links... wasn't able to see your information provided there. 

I did a packet capture on the meraki itself both for VPN interface and LAn interface

Both PCAP files showed icmp packets coming into the Meraki from the VPN assigned IP address as source and the internal 100.0.1.1 as destination.  I believe this shows that the Client side at least is not dumping/discarding the data packets, they are traversing the tunnel.  The MX appears to not be pushing these packets to next hop (which would be 100.0.1.2)

[alemabrahao]

I believe you are using Windows, right?

Try adding the route manually in Windows.

[RCMikesell]

I did try this as well and the results were the same, so routing out of windows to the MX isn't the issue.  I too had first assumed this was the most likely issue at first, but when it didn't work modified my theory. 

[RCMikesell]

Follow up on the situation and its resolution. 

Meraki was able to determine that the packets were reaching into the network

We setup a laptop internally in the network (with client help) that we put Wireshark on

We were able to see the pings coming in and being responded to.

Pings still not being seen from the VPN client

Checked the routing on the laptop and the Gateway was to a different location

Thus routing pushed any responses to that Gateway, not the Meraki

Added a rule on the laptop to route traffic from the VPN specific IP range and access was gained.