[Solved] Impossible use my local subnets while vpn organization is on

Hi everybody!
I have a problem with my openwrt.
I have some local subnets 192.168.96.0/19.
When I active my vpn client (from my organization), I can't ping anything anymore (exept for the device on the same subnet of my device), if i switched off the vpn everything come back again.

The routes print from my device show me that my organization pass all the 192.168.0.0/16 subnets. How can I "protect" my local subnets /19 from this settings? Should I make a ipv4 rules? routes? or similar??

Thanks to all the kindly people that can help me! =)

This is expected behavior. Is the VPN active on your OpenWrt router, or on a computer behind the router?

1 Like

Thanks for the support!
The vpn in active on my computer behind the router, I use the client software to connect via vpn

So this means you have 2 options:

  1. adjust the VPN/routes on your computer such that it doesn't try to tunnel your local subnets (i.e. exclude your specific subnets from the tunnel)
  2. Change your local subnets to something that doesn't conflict.

Option 1 is out of scope on these forums and may or may not actually be possible depending on the VPN protocol and how it sets up the routes on your system (and if you are able to override them) as well as the fact that it may cause you to be unable to reach key resources on the other side of that tunnel.

Option 2 is fairly straight forward -- move everything to a different major subnet. Since apparently the entire 192.168.0.0/16 block is being sent through the tunnel, you could move to the 172.16.0.0/12 or 10.0.0.0/8 blocks and it should work. This assumes, of course, that all traffic outside the 192.168.0.0/16 block is not tunneled through the VPN.

Thanks again. I was hoping that from openwrt I could make something to preserve my subnets anyway.
No problem, I will change all my subnets with something outside the tunnel
Thanks a lot!

Yeah, OpenWrt is not involved with and cannot affect the way the your VPN client software operates on your computer. But obviously it is possible to change OpenWrt's config to not conflict.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

I second that, but I would
a) switch the order of those steps and
b) do both steps at the same and

Assuming everyone in his right mind would only ever use /24 networks or smaller, the 10.0.0.0/8 range is a lot less likely to be in conflict. Especial if you think about only partial conflicts, I don't care if I'm in conflict with my corporate office printer network hundreds of miles away, I prefer reaching my local IoT network instead.

As for local routes taking precedence over VPN routes:

  • Routes might only apply partially in case there are conflicts
  • In general, routes to smaller networks take precedence over lager networks. This is sometimes described as "longest matching prefix length", which means "192.168.0.x wins over 192.168.x.x".
  • There's a thing called "metric", which means "in case of several routes, the one with the lowest metric number wins".

What you describe sounds like:

  • 0.0.0.0/0 via default gateway
  • 192.168.0.0/16 via VPN
  • 192.168.96.0/24 via default gateway

You could make your router just announce its additional route to 192.168.96.0/24 via DHCP with options 121 and 249.

Example:

cat /etc/config/dhcp

config dhcp 'office'
        option interface 'office'
        # assumes router IP to bei 192.168.96.1
        option start '192.168.96.50'
        option limit '50'
        option leasetime '30m'
        list dhcp_option '121,192.168.100.0/24,192.168.96.1,192.168.200.0/24,192.168.96.1'
        list dhcp_option '249,192.168.100.0/24,192.168.96.1,192.168.200.0/24,192.168.96.1'
config dhcp 'gaming'
        option interface 'gaming'
        # assumes router IP to bei 192.168.100.1
        option start '192.168.100.50'
        option limit '50'
        option leasetime '30m'
        list dhcp_option '121,192.168.94.0/24,192.168.100.1,192.168.200.0/24,192.168.100.1'
        list dhcp_option '249,192.168.94.0/24,192.168.100.1,192.168.200.0/24,192.168.100.1'

So DHCP options 121 and 249 basically announce a various number of additional routes to your local clients.

The format is basically comma separated. The first needs to be 121 (or 249 respectively). The second is a subnet format (x.x.x.x/y), the third part is the locally-reachable gateway that subnet is to be routed by. The fourth part would be another subnet, the firth part another router, and so on, and so on. So the number of parts your comma separated list of values has is always an odd number.

1 Like

While this is reasonable advice, the problem is that additional announced routes only help if the OS respects them and the VPN doesn't override them.

And while not being able to access a printer at the office may not be an issue, if the desired local subnets conflict with more important resources at the organization (let's say file servers, license servers, email systems, and so on), it's easiest to simply move the local subnets to avoid having to make complicated inclusion/exclusion lists to ensure proper access.

I don't know why the OP's organization is commandeering the entire 192.168.0.0/16 subnet block (and, for that matter, if the OP really does use all of the /19 space for their own subnets such as 32x /24's), but since all mitigation would need to happen on the computer (and not the router), the only way to guarantee that there would be no conflicts is to simply move the local subnets to a different block.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.