AP routing by VPN and rest by default

Note: ifconfig and route should not be used anymore on Linux because they use a deprecated and obsolete Linux kernel API. They should be replaced with ip link, ip addr and ip route (and various additional commands from the iproute2 suite).

Policy-based routing cannot be achieved with the deprecated commands on Linux but only with the iproute2 suite’s commands.

---

The current routing setup takes care of overriding the original default route by using two "half-default" routes instead of a default route (for example this is called def1 by OpenVPN when the server pushes a route or the client overrides it), so the actual VPN routes are both:

  0.0.0.0         10.8.3.1        128.0.0.0       UG        0 0          0 tun0
  128.0.0.0       10.8.3.1        128.0.0.0       UG        0 0          0 tun0

and because they are narrower than the default route, they override it for any destination (not in an other routing entry, such as the VPN remote endpoint explicitly added to avoid a routing loop for the tunnel envelope).

So removing only the first entry will still affect about half of Internet (eg: if www.armbian.com resolves as 5.161.66.254 it won’t be reached through the tunnel anymore, but if www.debian.org resolves as 128.31.0.62 then it will reached through the tunnel). Removing both of course will just more or less disable using the tunnel. These actions would affect the host and the nodes behind wlan0.

Here policy-based routing can be used to distinguish routed/forwarded traffic and traffic originating from the host itself to have a different routing outcome.

OP’s goal is to have the VPN used by the nodes behind the host (at the LAN behind wlan0) but not the host itself. Without any other change to the current setup, this can be manually accomplished by policy routing rules + a routing table overriding the current override: only for the host ignore routes with CIDR of 0 (0.0.0.0/0) or 1 (0.0.0.0/1 and 128.0.0.0/1: OpenVPN’s def1 method) and respecify a new default route (which will be the original default route).

The 3 commands below are sufficient to solve this:

ip route add default via 192.168.1.1 dev eth0 table 1000
ip rule add pref 1000 iif lo lookup main suppress_prefixlength 1
ip rule add pref 1001 iif lo lookup 1000

This will:

• only for the host itself (special syntax iif lo for host-originating traffic) but not for routed/forwarded traffic (which would match iif wlan0, iif eth0 or iif tun0 depending on where from, instead) use the main routing table to retrieve a route as long as the route doesn’t come from the default route or the two def1 "half-default" routes, thanks to the suppress_prefixlength suppressor.

• still only for the host itself if no route was found then use the original default route that was duplicated in routing table 1000.

  thus by default allowing the host to reach Internet without using the VPN.

Beside this:

• any routed/forwarded traffic is left unaffected by this setting

  and will thus continue as before to reach Internet through the VPN.

• return traffic to the host itself is always handled first by the local routing table so unaffected by this setup. Indeed the very first routing rule at preference 0 handles the local routing table, as seen below:

  # ip rule
  0:      from all lookup local
  1000:   from all iif lo lookup main suppress_prefixlength 1
  1001:   from all iif lo lookup 1000
  32766:  from all lookup main
  32767:  from all lookup default
  

• the host can still reach nodes at 10.8.3.0/24 as usual using the VPN or nodes at 192.168.2.0/24 through wireless since their routes have a CIDR of 24 which is superior to 1 and is thus not suppressed.

Caveat: whenever the interface eth0 is administratively put down (then up) the entry in routing table 1000 has to be put back because it will be deleted, just as what happens in the main routing table: this should be integrated in the eth0 interface setup rather than just at boot.

---

Other methods that don’t need to know explicitly the gateway or would automate this certainly exist, but they would likely involve the VPN setup. Either these commands could be run as a script by the VPN tool (which would probably be able to provide the gateway in a variable) or the VPN’s configuration might be able to provide direct solutions to solve this. I can’t know with available information.