1

I've re set-up my network and have started using VLANs to segregate my normal devices, homelab, and IoT devices. I have one device in the homelab VLAN that I want to be connected to a VPN at all times. I'm using PIA over OpenVPN. The trouble is once the device connects to the VPN it drops the SSH connection to my device (on the default VLAN) and I can no longer connect to it. I can hop to it through another machine in the homelab VLAN but this isn't great long term as I need to set up a web dashboard on the VPN connected device as well.

I'm a bit unfamiliar with this type of networking. I know something needs to be done on the client device to allow the connections from the default VLAN but I'm unsure what it is. For further information my router is a Dream Machine SE and I already have working traffic rules that allows the default VLAN to access the homelab VLAN.

Improve this question

1 Answer 1

Reset to default
1

It's mostly just a matter of route priority.

Every device uses its subnet mask to derive a route for its own subnet, which has priority over the 'default' route via PIA (simply due to being "more specific", e.g. a /24 route always wins over a /0 route), therefore the device will always be able to access its own subnet despite the VPN.

For your other subnets, this does not happen automatically – a device in subnet A does not know about subnet B or C and won't automatically have any specific routes to those subnets; it just uses its 'default' route to access them. So if the 'default' route has been overridden by your VPN client, the device no longer has any means to reach any of your other subnets except the one it's in.

You can avoid this by manually adding routes for all your subnets to that device (via its regular gateway, even if that seems redundant at first). For example, if all your VLANs are 192.168.x.0/24's, you could add the route 192.168.0.0/16 via 192.168.5.1. (It doesn't matter if you add exact routes for each subnet or if you add an aggregate route; either way it's still going to be more specific than the 'default' /0 route.)

Some devices can pick up such routes from DHCP (option 121 "Classless Static Route" and the equivalent pre-standard option 249 for older devices) avoiding the need for manual configuration all over the place.

Improve this answer
5
  • This is great info! Would you know generally how to do this via Unifi's interface?
    – Slayter
    Commented Feb 12 at 16:33
  • No, but you only need to touch UniFi if you want to deploy the routes via DHCP – in general the route addition needs to be done on the device, not on your gateway (the gateway already has the subnet routes because it is on all those subnets). At best I can provide a script to generate the values for the DHCP option, but I have no idea where to put it in UniFi.
    – grawity_u1686
    Commented Feb 12 at 16:38
  • Ah ok I was confused then. Where are these defined on the client device (assuming debian flavored linux)?
    – Slayter
    Commented Feb 12 at 17:01
  • 1
    If you're using Debian's ifupdown, you'll probably need to use post-up commands in /etc/network/interfaces, e.g. up ip route add x.y.z.t/u via ... (much like in shell). If you're using systemd-networkd, a [Route] section in the .network file. If you're using NetworkManager, there can be [ipv4] route= settings in the connection profile. All three support DHCP option 121 as far as I know.
    – grawity_u1686
    Commented Feb 12 at 17:04
  • Got this working. Thanks so much!
    – Slayter
    Commented Feb 12 at 17:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .