cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1854
Views
0
Helpful
2
Replies

Switch invisible to client VPN (Meraki MX65W)

Mathew5210
Level 1
Level 1

I'm starting to run out of things to try to get this working, so every random suggestion at this point would be helpful.
I've boiled the problem down to as simple a setup as I can.

 

Setup:

(internet-connected router) -> Meraki MX65W -> (Port 1: Device A, Port 2: TPLink T2600G managed switch)

- Everything is setup using a static IP, No DHCP is enabled

- Meraki subnet and IP (VLANs disabled): 192.168.0.10/24

- TPLink Access IP: 192.168.0.1 (reset switch to factory defaults, this is the IP it defaults to)

    - Note, everything defaults to vlan 1 on TPLink T2600G-28TS

- Device A: 192.168.0.123

- Meraki ClientVPN subnet: 192.168.128.0/24

 

Facts:

- Device A can ping Meraki and TPLink

- Meraki (using the ping tool in the Meraki web ui) can ping Device A and TPLink

- TPLink (using the ping tool in the TPLink web ui) can ping Device A and Meraki

- Client on ClientVPN can ping Meraki and Device A

 

Problem:

- Client on ClientVPN can NOT ping TPLink

 

Any ideas or suggestions or pointing out something I've done blatantly wrong would be amazing.

 

Mat.

1 Accepted Solution

Accepted Solutions

Solved:

Turns out I instinctively changed a config while doing the ping test from the switch to a client VPN device.

Specifically I added a static route on the switch for traffic on the VPN subnet, pointing back to the Meraki as the next hop.

 

Makes sense in hindsight now, the switch, which defaults to NOT having a default route, doesn't know where to send packets on a different subnet, and the Meraki isn't doing any nat'ing of client VPN devices.

 

So adding a static route (client vpn subnet)->(meraki on native switch subnet), lets the switch talk to the client VPN

View solution in original post

2 Replies 2

Mathew5210
Level 1
Level 1

Update:

Initially, a VPN client could NOT ping the TPLink switch, so I tried pinging a VPN Client from the switch (using the ping tool in the switch's web ui). That worked, and once that worked, the client VPN could also ping the TPLink switch.

 

I feel uneasy about accepting that it works now and moving on without understanding why. Can anyone help explain this behaviour?

 

Cheers.

Solved:

Turns out I instinctively changed a config while doing the ping test from the switch to a client VPN device.

Specifically I added a static route on the switch for traffic on the VPN subnet, pointing back to the Meraki as the next hop.

 

Makes sense in hindsight now, the switch, which defaults to NOT having a default route, doesn't know where to send packets on a different subnet, and the Meraki isn't doing any nat'ing of client VPN devices.

 

So adding a static route (client vpn subnet)->(meraki on native switch subnet), lets the switch talk to the client VPN