05-20-2019 08:05 PM
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.
Solved! Go to Solution.
05-20-2019 10:41 PM
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
05-20-2019 08:43 PM
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.
05-20-2019 10:41 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide