How can I manually configure an application split tunnel in wireguard?

Question

I'm having a hard time configuring a NAS I have for a fairly unusual use case. I want a persistent configuration for the NAS to route all traffic through wireguard except for ssh from my home network. The trouble is that the NAS (running debian) sits on a VLAN separate from the rest of my home network in 192.168.2.0/24, while the rest of my home network is on 192.168.1.0/24, so ssh is only accessible by port forwarding between the VLANs, and therefore, excluding my home subnets from AllowedIPs did not work. Any solution to configure wireguard to allow responses to ssh traffic behind NAT would solve my problem.

A partial solution that I've gotten to work is to use the automatic split tunneling with the mullvad utility (from my VPN provider), which excludes a list of processes from being routed through the VPN interface. I found the pid of sshd and added it to the exclude list like so:

% ps aux | grep sshd
    root    xxxx    ..... sshd: /usr/sbin/sshd ....
% mullvad split-tunnel pid add xxxx

Then it behaves as I want it to. I suppose I could have a script that runs at startup that finds the pid for sshd and adds it as I've done manually, but it bothers me that I don't understand what it's doing behind the scenes, and it seems a bit hacky.

I've tried to figure out what happens behind the scenes when I use the mullvad utility's split tunnel feature and can't find anything. If I check the firewall rules % nft list ruleset, there's nothing related to sshd's pid. Moreover, if I disable the firewall altogether, I am still unable to get ssh access without the split tunnel feature.

If I check % ip route or % ip link either with or without mullvad's split tunnel feature, the results are identical

% ip route
default via 192.168.2.1 dev enp0sx proto dhcp src 192.168.2.x metric 202
xxx.xxx.xxx.xxx dev wg-mullvad proto static
192.168.2.0/24 dev enp0sx proto dhcp scope link src 192.168.2.x metric 202
% ip link
....
wg-mullvad: <POINTOPOINT,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/none

The difference I've noticed is that with the split tunnel feature on, there is a fwmark: 0xyyyyyyyy in the interface output of % wg, which corresponds to an ip rule

% ip rule
0: from all lookup local
32764: from all lookup main suppress_prefixlength 0
32765: not from all fwmark 0xyyyyyyy lookup zzzzzzzzzz
32766: from all lookup main
32767: from all lookup default

I'm not sure what this is doing, or where the list of process pids is configured, and I haven't been able to understand the wireguard documentation. I think I'm just in a little over my head with routing tables and I'm not sure what to look for to understand. Any help configuring this manually or just pointing me to the right documentation would solve my problem.

I suppose it might also matter what other wireguard options are used. For reference, the default wireguard config from mullvad which works to route all traffic (wg-quick up mullvad) is the following:

# /etc/wireguard/mullvad.conf

[Interface]
PrivateKey = xxxxxxxxxxxxxxxx
Address = x.x.x.x/32, fc00:x:x:x::x/128
DNS = x.x.x.x

[Peer]
PublicKey = xxxxxxxxxxxxxxxx
AllowedIPs = 0.0.0.0/0,::0/0
Endpoint = x.x.x.x:x

Thanks :)

Answer 1

You want to route traffic to your home network (192.168.1.0/24) the same way as you route traffic to your NAS network (192.168.2.0/24), so like Daniel B suggested, add a route specifically for your home network that uses the same gateway as your NAS network:

ip route add 192.168.1.0/24 via 192.168.2.1 dev enp0sx

If you have a /0 block in your WireGuard AllowedIPs setting, wg-quick will always add the suppress_prefixlength and fwmark policy-routing rules you noted -- those rules tell the kernel to skip the default route in your main table and instead use the custom table zzzzzzzzzz that wg-quick sets up for this case (except for traffic with your WireGuard endpoint, which WireGuard marks with 0xyyyyyyy). Those rules are what send all traffic without a specific route defined for it through the WireGuard tunnel. They effectively override the default route in your main table which would normally send that traffic to your LAN router 192.168.2.1.