SSH into the UDM/P (assuming it's on 192.168.1.254).

ssh [email protected]

Download the scripts package, extract it to /mnt/data/split-vpn/vpn, and give it executable permissions.

cd /mnt/data
mkdir -p /mnt/data/split-vpn && cd /mnt/data/split-vpn
curl -L https://github.com/peacey/split-vpn/archive/main.zip | unzip - -o
cp -rf split-vpn-main/vpn ./ && rm -rf split-vpn-main
chmod +x vpn/*.sh vpn/hooks/*/*.sh vpn/vpnc-script

Create a directory for your VPN provider's openvpn configuration files, and copy your VPN's configuration files (certificates, config, password files, etc) and the sample vpn.conf from /mnt/data/split-vpn/vpn/vpn.conf.sample. NordVPN is used below as an example.

mkdir -p /mnt/data/split-vpn/openvpn/nordvpn
cd /mnt/data/split-vpn/openvpn/nordvpn
curl https://downloads.nordcdn.com/configs/files/ovpn_legacy/servers/us-ca12.nordvpn.com.udp1194.ovpn --out nordvpn.ovpn
cp /mnt/data/split-vpn/vpn/vpn.conf.sample /mnt/data/split-vpn/openvpn/nordvpn/vpn.conf

If your VPN provider uses a username/password, put them in a username_password.txt file in the same directory as the configuration with the username on the first line and password on the second line. Then either:

• Edit your VPN provider's openvpn config you downloaded in step 3 to reference the username_password.txt file by adding/changing this directive: auth-user-pass username_password.txt.
• Use the --auth-user-pass username_password.txt option when you run openvpn below in step 6 or 8.

NOTE: The username/password for openvpn are usually given to you in a file or in your VPN provider's online portal. They are usually not the same as your login to the VPN.

Edit the vpn.conf file with your desired settings. See the explanation of each setting below.

Run OpenVPN in the foreground to test if everything is working properly.

openvpn --config nordvpn.ovpn \
        --route-noexec --redirect-gateway def1 \
        --up /mnt/data/split-vpn/vpn/updown.sh \
        --down /mnt/data/split-vpn/vpn/updown.sh \
        --script-security 2

If the connection works, check each client to make sure they are on the VPN by doing the following.

• Check if you are seeing the VPN IPs when you visit http://whatismyip.host/. You can also test from command line, by running the following commands from your clients. Make sure you are not seeing your real IP anywhere, either IPv4 or IPv6.

  curl -4 ifconfig.co
  curl -6 ifconfig.co

  If you are seeing your real IPv6 address above, make sure that you are forcing your client through IPv6 as well as IPv4, by forcing through interface, MAC address, or the IPv6 directly. If IPv6 is not supported by your VPN provider, the IPv6 check will time out and not return anything. You should never see your real IPv6 address.

• Check for DNS leaks with the Extended Test on https://www.dnsleaktest.com/. If you see a DNS leak, try redirecting DNS with the DNS_IPV4_IP and DNS_IPV6_IP options, or set DNS_IPV6_IP="REJECT" if your VPN provider does not support IPv6.

• Check for WebRTC leaks in your browser by visiting https://browserleaks.com/webrtc. If WebRTC is leaking your IPv6 IP, you need to disable WebRTC in your browser (if possible), or disable IPv6 completely by disabling it directly on your client or through the UDMP network settings for the client's VLAN.

If everything is working properly, stop the OpenVPN client by pressing Ctrl+C, and then run it in the background with the following command. If you want to enable the killswitch to block Internet access to forced clients if OpenVPN crashes, set KILLSWITCH=1 in the vpn.conf file before starting OpenVPN. If you also want to block Internet access to forced clients when you exit OpenVPN cleanly (with SIGTERM), then set REMOVE_KILLSWITCH_ON_EXIT=0.

nohup openvpn --config nordvpn.ovpn \
              --route-noexec --redirect-gateway def1 \
              --up /mnt/data/split-vpn/vpn/updown.sh \
              --down /mnt/data/split-vpn/vpn/updown.sh \
              --script-security 2 \
              --ping-restart 15 \
              --mute-replay-warnings &> openvpn.log &

You can modify the command to change --ping-restart or other options as needed. The only requirement is that you run updown.sh script as the up/down script and --route-noexec to disable OpenVPN from adding routes to the default table instead of our custom one. In some cases, --redirect-gateway def1 is needed to set the correct VPN gateway.

Now you can exit the UDM/P. If you would like to start the VPN client at boot, please read on to the next section.

If your VPN provider doesn't support IPv6, it is recommended to disable IPv6 for that VLAN in the UDMP settings, or on the client, so that you don't encounter any delays. If you don't disable IPv6, clients on that network will try to communicate over IPv6 first and fail, then fallback to IPv4. This creates a delay that can be avoided if IPv6 is turned off completely for that network or client.

SSH into the UDM/P (assuming it's on 192.168.1.254).

ssh [email protected]

Download the scripts package, extract it to /mnt/data/split-vpn/vpn, and give it executable permissions.

cd /mnt/data
mkdir -p /mnt/data/split-vpn && cd /mnt/data/split-vpn
curl -L https://github.com/peacey/split-vpn/archive/main.zip | unzip - -o
cp -rf split-vpn-main/vpn ./ && rm -rf split-vpn-main
chmod +x vpn/*.sh vpn/hooks/*/*.sh vpn/vpnc-script

Create a directory for your WireGuard configuration files, copy the sample vpn.conf from /mnt/data/split-vpn/vpn/vpn.conf.sample, and copy your WireGuard configuration file (wg0.conf) or create it. As an example below, we are creating the wg0.conf file that mullvad provides and pasting the contents into it. You can use any name for your config instead of wg0 (e.g.: mullvad-ca2.conf) and this will be the interface name of the wireguard tunnel.

mkdir -p /mnt/data/split-vpn/wireguard/mullvad
cd /mnt/data/split-vpn/wireguard/mullvad
cp /mnt/data/split-vpn/vpn/vpn.conf.sample /mnt/data/split-vpn/wireguard/mullvad/vpn.conf
vim wg0.conf
[Press 'i' to start editing, right click -> paste, press 'ESC' to exit insert mode, type ':wq' to save and exit].

In your WireGuard config (wg0.conf), set PreUp, PostUp, and PreDown to point to the updown.sh script, and Table to a custom route table number that you will use in this script's vpn.conf. Here is an exmaple wg0.conf file:

[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address = 10.68.1.88/32,fc00:dddd:eeee:bb01::5:6666/128
PreUp = sh /mnt/data/split-vpn/vpn/updown.sh %i pre-up
PostUp = sh /mnt/data/split-vpn/vpn/updown.sh %i up
PreDown = sh /mnt/data/split-vpn/vpn/updown.sh %i down
Table = 101

[Peer]
PublicKey = yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
AllowedIPs = 0.0.0.0/1,128.0.0.0/1,::/1,8000::/1
Endpoint = [2607:f7a0:d:4::a02f]:51820

In the above config, make sure to:

• Comment out or remove the DNS line. Use the DNS settings in your vpn.conf file instead if you want to force your clients to use a certain DNS server.
• Set AllowedIPs to 0.0.0.0/1,128.0.0.0/1,::/1,8000::/1 to allow all IPv4 and IPv6 traffic through the VPN. Do not use 0.0.0.0/0,::/0 because it will interfere with the blackhole routes and won't allow wireguard to start. If you prefer to use 0.0.0.0/0,::/0, disable blackhole routes by setting DISABLE_BLACKHOLE=1 in your vpn.conf file so wireguard can start successfully.
• Remove any extra PreUp/PostUp/PreDown/PostDown lines that could interfere with the VPN script.
• You can remove or comment out the PreUp line if you do not want VPN-forced clients to lose Internet access if WireGuard does not start correctly.

Edit the vpn.conf file with your desired settings. See the explanation of each setting below. Make sure that:

• The option DNS_IPV4_IP and/or DNS_IPV6_IP is set to the DNS server you want to force for your clients, or set them to empty if you do not want to force any DNS.
• The option VPN_PROVIDER is set to "external".
• The option VPN_ENDPOINT_IPV4 or VPN_ENDPOINT_IPV6 is set to your WireGuard server's IP as defined in wg0.conf's Endpoint variable.
• The option ROUTE_TABLE is the same number as Table in your wg0.conf file.
• The option DEV is set to "wg0" or your interface's name if different (i.e.: the name of your .conf file).

Run wg-quick to start wireguard with your configuration and test if the connection worked.

/mnt/data/wireguard/setup_wireguard.sh
wg-quick up ./wg0.conf

• You can skip the first line if you already setup the wireguard kernel module previously as instructed at wireguard-kmod.
• Type wg to check your WireGuard connection and make sure you received a handshake. No handshake indicates something is wrong with your wireguard configuration. Double check your configuration's Private and Public key and other variables.
• If you need to bring down the WireGuard tunnel, run wg-quick down wg0.conf in this folder.
• Note that wg-quick up/down commands need to be run from this folder so the script can pick up the correct configuration file.

If the connection works, check each client to make sure they are on the VPN by doing the following.

• Check if you are seeing the VPN IPs when you visit http://whatismyip.host/. You can also test from command line, by running the following commands from your clients (not the UDM/P). Make sure you are not seeing your real IP anywhere, either IPv4 or IPv6.

  curl -4 ifconfig.co
  curl -6 ifconfig.co

  If you are seeing your real IPv6 address above, make sure that you are forcing your client through IPv6 as well as IPv4, by forcing through interface, MAC address, or the IPv6 directly. If IPv6 is not supported by your VPN provider, the IPv6 check will time out and not return anything. You should never see your real IPv6 address.

• Check for DNS leaks with the Extended Test on https://www.dnsleaktest.com/. If you see a DNS leak, try redirecting DNS with the DNS_IPV4_IP and DNS_IPV6_IP options, or set DNS_IPV6_IP="REJECT" if your VPN provider does not support IPv6.

• Check for WebRTC leaks in your browser by visiting https://browserleaks.com/webrtc. If WebRTC is leaking your IPv6 IP, you need to disable WebRTC in your browser (if possible), or disable IPv6 completely by disabling it directly on your client or through the UDMP network settings for the client's VLAN.

If you want to block Internet access to forced clients if the wireguard tunnel is brought down via wg-quick, set KILLSWITCH=1 and REMOVE_KILLSWITCH_ON_EXIT=0 in the vpn.conf file.

Now you can exit the UDM/P. If you would like to start the VPN client at boot, please read on to the next section.

If your VPN provider doesn't support IPv6, it is recommended to disable IPv6 for that VLAN in the UDMP settings, or on the client, so that you don't encounter any delays. If you don't disable IPv6, clients on that network will try to communicate over IPv6 first and fail, then fallback to IPv4. This creates a delay that can be avoided if IPv6 is turned off completely for that network or client.

Note that the WireGuard protocol is practically stateless, so there is no way to know whether the connection stopped working except by checking that you didn't receive a handshake within 3 minutes or some higher interval. This means if you want to automatically bring down the split-vpn rules when WireGuard stops working and bring it back up when it starts working again, you need to write an external script to check the last handshake condition every few seconds and act on it (not covered here).

SSH into the UDM/P (assuming it's on 192.168.1.254).

ssh [email protected]

Download the scripts package, extract it to /mnt/data/split-vpn/vpn, and give it executable permissions.

cd /mnt/data
mkdir -p /mnt/data/split-vpn && cd /mnt/data/split-vpn
curl -L https://github.com/peacey/split-vpn/archive/main.zip | unzip - -o
cp -rf split-vpn-main/vpn ./ && rm -rf split-vpn-main
chmod +x vpn/*.sh vpn/hooks/*/*.sh vpn/vpnc-script

Create a directory for your WireGuard configuration files under /mnt/data/wireguard if not created already, copy the sample vpn.conf from /mnt/data/split-vpn/vpn/vpn.conf.sample, and copy your WireGuard configuration file (wg0.conf) or create it. As an example below, we are creating the wg0.conf file that mullvad provides and pasting the contents into it. You can only use wg0.conf and not any other name because the wireguard-go container expects this configuration file.

mkdir -p /mnt/data/wireguard
cd /mnt/data/wireguard
cp /mnt/data/split-vpn/vpn/vpn.conf.sample /mnt/data/wireguard/vpn.conf
vim wg0.conf
[Press 'i' to start editing, right click -> paste, press 'ESC' to exit insert mode, type ':wq' to save and exit].

In your WireGuard config (wg0.conf), set Table to a custom route table number that you will use in this script's vpn.conf. Here is an exmaple wg0.conf file:

[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address = 10.68.1.88/32,fc00:dddd:eeee:bb01::5:6666/128
Table = 101

[Peer]
PublicKey = yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
AllowedIPs = 0.0.0.0/1,128.0.0.0/1,::/1,8000::/1
Endpoint = [2607:f7a0:d:4::a02f]:51820

In the above config, make sure to:

• Comment out or remove the DNS line. Use the DNS settings in your vpn.conf file instead if you want to force your clients to use a certain DNS server.
• Set AllowedIPs to 0.0.0.0/1,128.0.0.0/1,::/1,8000::/1 to allow all IPv4 and IPv6 traffic through the VPN. Do not use 0.0.0.0/0,::/0 because it will interfere with the blackhole routes and won't allow wireguard to start. If you prefer to use 0.0.0.0/0,::/0, disable blackhole routes by setting DISABLE_BLACKHOLE=1 in your vpn.conf file so wireguard can start successfully.
• Remove any extra PreUp/PostUp/PreDown/PostDown lines that could interfere with the VPN script.
• Do not use PreUp/PostUp/PreDown to call the split-vpn script (like in the wireguard kernel module case) because the container will not have access to the location of the script. Instead, we will call the script manually after bringing the interface up/down as instructed below.

Edit the vpn.conf file with your desired settings. See the explanation of each setting below. Make sure that:

• The option DNS_IPV4_IP and/or DNS_IPV6_IP is set to the DNS server you want to force for your clients, or set them to empty if you do not want to force any DNS.
• The option VPN_PROVIDER is set to "external".
• The option VPN_ENDPOINT_IPV4 or VPN_ENDPOINT_IPV6 is set to your WireGuard server's IP as defined in wg0.conf's Endpoint variable.
• The option ROUTE_TABLE is the same number as Table in your wg0.conf file.
• The option DEV is set to "wg0".

Modify your run script that you installed with wireguard-go (located at /mnt/data/on_boot.d/20-wireguard.sh) to include the split-vpn script hooks by replacing it with the following code:

#!/bin/sh
CONTAINER=wireguard

# Change to the directory with the wireguard configuration.
cd /mnt/data/wireguard

# Start the split-vpn pre-up hook.
/mnt/data/split-vpn/vpn/updown.sh wg0 pre-up &> pre-up.log

# Starts a wireguard container that is deleted after it is stopped.
# All configs stored in /mnt/data/wireguard
if podman container exists ${CONTAINER}; then
  podman start ${CONTAINER}
else
  podman run -i -d --rm --net=host --name ${CONTAINER} --privileged \
    -v /mnt/data/wireguard:/etc/wireguard \
    -v /dev/net/tun:/dev/net/tun \
    -e LOG_LEVEL=info -e WG_COLOR_MODE=always \
    masipcat/wireguard-go:latest-arm64v8
fi

# Run the split-vpn up hook if wireguard starts successfully within 5 seconds.
started=0
for i in $(seq 1 5); do
        podman exec -it wireguard test -S "/var/run/wireguard/wg0.sock" &> /dev/null
        if [ $? = 0 ]; then
                started=1
                break
        fi
        sleep 1
done
if [ $started = 1 ]; then
        echo "wireguard-go started successfully." > wireguard.log
        /mnt/data/split-vpn/vpn/updown.sh wg0 up >> wireguard.log 2>&1
else
        echo "Error: wireguard-go did not start up correctly within 5 seconds." > wireguard.log
fi
cat wireguard.log

• Comment out the pre-up line at the beginning if you want your forced clients to be able to access the Internet if wireguard fails to start (i.e. commenting it out doesn't enable the iptables kill switch until after the VPN tunnel is brought up).
• The above script will wait up to 5 seconds for the wireguard-go container to start before running the split-vpn up hook to set up the split-vpn rules. The split-vpn up hook will not be run if wireguard-go did not start up correctly.

Run the 20-wireguard.sh script: /mnt/data/on_boot.d/20-wireguard.sh.

If wireguard-go started successfully, check that the connection worked by seeing if you received a handshake with the following command:

podman exec -it wireguard wg

• No handshake in the above output indicates something is wrong with your wireguard configuration. Double check your configuration's Private and Public key and other variables.

• If you need to bring down the WireGuard tunnel and resume normal Internet access to your forced clients, run the following commands in this folder:

  cd /mnt/data/wireguard
  podman stop wireguard
  /mnt/data/split-vpn/vpn/updown.sh wg0 down

• Note that split-vpn up/down commands need to be run from this folder so that split-vpn can pick up the correct configuration file.

If the connection works, check each client to make sure they are on the VPN by doing the following.

• Check if you are seeing the VPN IPs when you visit http://whatismyip.host/. You can also test from command line, by running the following commands from your clients (not the UDM/P). Make sure you are not seeing your real IP anywhere, either IPv4 or IPv6.

  curl -4 ifconfig.co
  curl -6 ifconfig.co

  If you are seeing your real IPv6 address above, make sure that you are forcing your client through IPv6 as well as IPv4, by forcing through interface, MAC address, or the IPv6 directly. If IPv6 is not supported by your VPN provider, the IPv6 check will time out and not return anything. You should never see your real IPv6 address.

• Check for DNS leaks with the Extended Test on https://www.dnsleaktest.com/. If you see a DNS leak, try redirecting DNS with the DNS_IPV4_IP and DNS_IPV6_IP options, or set DNS_IPV6_IP="REJECT" if your VPN provider does not support IPv6.

• Check for WebRTC leaks in your browser by visiting https://browserleaks.com/webrtc. If WebRTC is leaking your IPv6 IP, you need to disable WebRTC in your browser (if possible), or disable IPv6 completely by disabling it directly on your client or through the UDMP network settings for the client's VLAN.

If you want to continue blocking Internet access to forced clients after the wireguard tunnel is brought down via the split-vpn down command, set KILLSWITCH=1 and REMOVE_KILLSWITCH_ON_EXIT=0 in the vpn.conf file.

Now you can exit the UDM/P. If you would like to start the VPN client at boot, please read on to the next section.

If your VPN provider doesn't support IPv6, it is recommended to disable IPv6 for that VLAN in the UDMP settings, or on the client, so that you don't encounter any delays. If you don't disable IPv6, clients on that network will try to communicate over IPv6 first and fail, then fallback to IPv4. This creates a delay that can be avoided if IPv6 is turned off completely for that network or client.

Note that the WireGuard protocol is practically stateless, so there is no way to know whether the connection stopped working except by checking that you didn't receive a handshake within 3 minutes or some higher interval. This means if you want to automatically bring down the split-vpn rules when WireGuard stops working and bring it back up when it starts working again, you need to write an external script to check the last handshake condition every few seconds and act on it (not covered here).

SSH into the UDM/P (assuming it's on 192.168.1.254).

ssh [email protected]

Download the scripts package, extract it to /mnt/data/split-vpn/vpn, and give it executable permissions.

cd /mnt/data
mkdir -p /mnt/data/split-vpn && cd /mnt/data/split-vpn
curl -L https://github.com/peacey/split-vpn/archive/main.zip | unzip - -o
cp -rf split-vpn-main/vpn ./ && rm -rf split-vpn-main
chmod +x vpn/*.sh vpn/hooks/*/*.sh vpn/vpnc-script

Create a directory for your OpenConnect configuration files under /mnt/data/split-vpn/openconnect, copy the sample vpn.conf from /mnt/data/split-vpn/vpn/vpn.conf.sample, and copy any certificates needed or other client files for your configuration. As an example below, we are going to connect a server that only uses a username/password, so no certificate is needed, but we have to create a password.txt file and put the password inside it.

mkdir -p /mnt/data/split-vpn/openconnect/server1
cd /mnt/data/split-vpn/openconnect/server1
cp /mnt/data/split-vpn/vpn/vpn.conf.sample vpn.conf
echo "mypassword" > password.txt

Edit the vpn.conf file in this folder with your desired settings. See the explanation of each setting below. Make sure that:

• The options DNS_IPV4_IP and DNS_IPV6_IP are set to "DHCP" if you want to force VPN-forced clients to use the DNS provided by the VPN server.
• The option VPN_PROVIDER is set to "openconnect". This is required for the script to work with OpenConnect.

In the current folder, create a run script that will run the OpenConnect container called run-vpn.sh, and fill it with the following code:

• Tip: Run the vim text editor using vim run-vpn.sh, press 'i' to enter insert mode, right click on vim -> paste, press 'ESC' to exit insert mode, type ':wq' to save and exit.

#!/bin/sh
cd "/mnt/data/split-vpn/openconnect/server1"
source ./vpn.conf
podman rm -f openconnect-${DEV} &> /dev/null
/mnt/data/split-vpn/vpn/updown.sh ${DEV} pre-up
podman run -id --privileged  --name=openconnect-${DEV} \
    --network host --pid=host \
    -e TZ="$(cat /etc/timezone)" \
    -v "${PWD}:/etc/split-vpn/config" \
    -v "/mnt/data/split-vpn/vpn:/etc/split-vpn/vpn" \
    -w "/etc/split-vpn/config" \
    --restart on-failure \
    peacey/udm-openconnect \
    bash -c "openconnect -s /etc/split-vpn/vpn/vpnc-script -i ${DEV} --reconnect-timeout 1 -u myusername --passwd-on-stdin vpn.server1.com < password.txt &> openconnect.log"

• Make sure the 2nd line points to the correct directory with your vpn configuration files.
• You can modify the options to openconnect in the last line for other authentication types (like certificates). See the OpenConnect authentication options here. These parameters are for a server that uses a username/password to login.
• Make sure you change "myusername" in the last line to your username, and "vpn.server1.com" to your VPN server's domain or IP. Make sure you also created the password.txt file with your password.
• The --restart on-failure will make podman try to restart the VPN connection if OpenConnect exits because of a connection error. You can also modify the reconnect timeout via the --reconnect-timeout 1 option to openconnect in the last line.
• If you do not want to run the VPN in the background (e.g. for testing), remove the "d" from podman run -id in the 5th line.
• This code writes the output to openconnect.log in the current folder.

Give the script executable permissions.

The first time the script runs, it will download the OpenConnect docker container. If the container ran successfully, you should see a random string of numbers and letters. Warnings about major/minor number can be ignored.

• If the script ran successfully, check the openconnect.log file by running cat openconnect.log. If the connection is working, you should see that OpenConnect established a connection without errors and that split-vpn ran.

If the connection works, check each client to make sure they are on the VPN by doing the following.

• Check if you are seeing the VPN IPs when you visit http://whatismyip.host/. You can also test from command line, by running the following commands from your clients (not the UDM/P). Make sure you are not seeing your real IP anywhere, either IPv4 or IPv6.

  curl -4 ifconfig.co
  curl -6 ifconfig.co

  If you are seeing your real IPv6 address above, make sure that you are forcing your client through IPv6 as well as IPv4, by forcing through interface, MAC address, or the IPv6 directly. If IPv6 is not supported by your VPN provider, the IPv6 check will time out and not return anything. You should never see your real IPv6 address.

• Check for DNS leaks with the Extended Test on https://www.dnsleaktest.com/. If you see a DNS leak, try redirecting DNS with the DNS_IPV4_IP and DNS_IPV6_IP options, or set DNS_IPV6_IP="REJECT" if your VPN provider does not support IPv6.

• Check for WebRTC leaks in your browser by visiting https://browserleaks.com/webrtc. If WebRTC is leaking your IPv6 IP, you need to disable WebRTC in your browser (if possible), or disable IPv6 completely by disabling it directly on your client or through the UDMP network settings for the client's VLAN.

If you want to continue blocking Internet access to forced clients after the openconnect client is shut down, set KILLSWITCH=1 and REMOVE_KILLSWITCH_ON_EXIT=0 in the vpn.conf file.

Now you can exit the UDM/P. If you would like to start the VPN client at boot, please read on to the next section.

If your VPN provider doesn't support IPv6, it is recommended to disable IPv6 for that VLAN in the UDMP settings, or on the client, so that you don't encounter any delays. If you don't disable IPv6, clients on that network will try to communicate over IPv6 first and fail, then fallback to IPv4. This creates a delay that can be avoided if IPv6 is turned off completely for that network or client.

After your VPN computer is set up correctly, SSH into the UDM/P (assuming it's on 192.168.1.254).

ssh [email protected]

Download the scripts package, extract it to /mnt/data/split-vpn/vpn, and give it executable permissions.

cd /mnt/data
mkdir -p /mnt/data/split-vpn && cd /mnt/data/split-vpn
curl -L https://github.com/peacey/split-vpn/archive/main.zip | unzip - -o
cp -rf split-vpn-main/vpn ./ && rm -rf split-vpn-main
chmod +x vpn/*.sh vpn/hooks/*/*.sh vpn/vpnc-script

Create a directory for your VPN configuration, and copy the sample vpn.conf from /mnt/data/split-vpn/vpn/vpn.conf.sample.

mkdir -p /mnt/data/split-vpn/nexthop/mycomputer
cd /mnt/data/split-vpn/nexthop/mycomputer
cp /mnt/data/split-vpn/vpn/vpn.conf.sample vpn.conf

Edit the vpn.conf file with your desired settings. See the explanation of each setting below. Make sure that:

• The option GATEWAY_TABLE is set to "disabled" if your nexthop computer is on your LAN (most likely it is, as you wouldn't want to send unencrypted traffic over your WAN). The connection will not work if GATEWAY_TABLE is not set to "disbaled" for LAN computers.
• The option VPN_PROVIDER is set to "nexthop".
• The option VPN_ENDPOINT_IPV4 and VPN_ENDPOINT_IPV6 is set to the IP of the computer on your network that is running the VPN client that you want to redirect traffic to. If your VPN computer does not support IPv6, then only set the IPv4 address.
• The option DEV is set to the bridge interface that your VPN computer is on, for example "br0" for main LAN or "br6" for VLAN 6 (i.e.: VLAN X is on interface brX).

Run the split-vpn up command in this folder to bring up the rules to force traffic to the VPN. Change "br0" to the interface your VPN computer is on, and "mycomputer" to the nickname you want to refer to this computer with when you bring down the VPN connection.

/mnt/data/split-vpn/vpn/updown.sh br0 up mycomputer

• If you need to bring down the WireGuard tunnel and resume normal Internet access to your forced clients, run the following commands in this folder:

cd /mnt/data/split-vpn/nexthop/mycomputer
/mnt/data/split-vpn/vpn/updown.sh br0 down mycomputer

Check each client to make sure they are on the VPN by doing the following.

• Check if you are seeing the VPN IPs when you visit http://whatismyip.host/. You can also test from command line, by running the following commands from your clients (not the UDM/P). Make sure you are not seeing your real IP anywhere, either IPv4 or IPv6.

  curl -4 ifconfig.co
  curl -6 ifconfig.co

  If you are seeing your real IPv6 address above, make sure that you are forcing your client through IPv6 as well as IPv4, by forcing through interface, MAC address, or the IPv6 directly. If IPv6 is not supported by your VPN provider, the IPv6 check will time out and not return anything. You should never see your real IPv6 address.

• Check for DNS leaks with the Extended Test on https://www.dnsleaktest.com/. If you see a DNS leak, try redirecting DNS with the DNS_IPV4_IP and DNS_IPV6_IP options, or set DNS_IPV6_IP="REJECT" if your VPN provider does not support IPv6.

• Check for WebRTC leaks in your browser by visiting https://browserleaks.com/webrtc. If WebRTC is leaking your IPv6 IP, you need to disable WebRTC in your browser (if possible), or disable IPv6 completely by disabling it directly on your client or through the UDMP network settings for the client's VLAN.

If you want to block Internet access to forced clients if the wireguard tunnel is brought down via wg-quick, set KILLSWITCH=1 and REMOVE_KILLSWITCH_ON_EXIT=0 in the vpn.conf file.

Now you can exit the UDM/P. If you would like to start the VPN client at boot, please read on to the next section.

If your VPN provider doesn't support IPv6, it is recommended to disable IPv6 for that VLAN in the UDMP settings, or on the client, so that you don't encounter any delays. If you don't disable IPv6, clients on that network will try to communicate over IPv6 first and fail, then fallback to IPv4. This creates a delay that can be avoided if IPv6 is turned off completely for that network or client.

Create a new file under /mnt/data/on_boot.d/99-run-vpn.sh and fill it with the following.

#!/bin/sh
# Load configuration and run openvpn
cd /mnt/data/split-vpn/openvpn/nordvpn
source ./vpn.conf
/mnt/data/split-vpn/vpn/updown.sh ${DEV} pre-up &> pre-up.log
nohup openvpn --config nordvpn.ovpn \
              --route-noexec --redirect-gateway def1 \
              --up /mnt/data/split-vpn/vpn/updown.sh \
              --down /mnt/data/split-vpn/vpn/updown.sh \
              --dev-type tun --dev ${DEV} \
              --script-security 2 \
              --ping-restart 15 \
              --mute-replay-warnings &> openvpn.log &

• Remember to modify the cd line and the --config openvpn option to point to your config.
• Comment out the pre-up line if you want your forced clients to be able to access the Internet while the VPN is connecting (i.e. commenting it out doesn't enable the iptables kill switch until after OpenVPN connects).

Run chmod +x /mnt/data/on_boot.d/99-run-vpn.sh to give the script execute permissions.

That's it. Now the VPN will start at every boot.

Note that there is a short period between when the UDMP starts and when this script runs. This means there is a few seconds when the UDMP starts up when your forced clients WILL have access to your WAN and might leak their real IP, because the kill switch has not been activated yet. Read the queston How can I block Internet access until after this script runs at boot? in the FAQ below to see how to solve this problem and block Internet access until after this script runs.

Create a new file under /mnt/data/on_boot.d/99-run-vpn.sh and fill it with the following.

#!/bin/sh

# Set up the wireguard kernel module and tools
/mnt/data/wireguard/setup_wireguard.sh

# Load configuration and run wireguard
cd /mnt/data/split-vpn/wireguard/mullvad
source ./vpn.conf
/mnt/data/split-vpn/vpn/updown.sh ${DEV} pre-up &> pre-up.log
wg-quick up ./${DEV}.conf &> wireguard.log
cat wireguard.log

• Comment out the pre-up line if you want your forced clients to be able to access the Internet if wireguard fails to start (i.e. commenting it out doesn't enable the iptables kill switch until after the VPN tunnel is brought up).
• It is preferrable to separately run the pre-up hook like the above script instead of using wg-quick's PreUp hook in case wg-quick did not get set up correctly. wg-quick and the wireguard kernel module depends on the kernel version so might fail spontaneously if your UDM/P performs a software update.
• You can remove the setup_wireguard.sh line if you have another boot script that sets up the kernel module before this run script. Just make sure that this script runs after the setup script by prefixing each script with a number to determine priority (e.g.: 90-setup-wireguard.sh and 99-run-vpn.sh).

Run chmod +x /mnt/data/on_boot.d/99-run-vpn.sh to give the script execute permissions.

That's it. Now the VPN will start at every boot.

OPTIONAL: Note that there is a short period between when the UDMP starts and when this script runs. This means there is a few seconds when the UDMP starts up when your forced clients WILL have access to your WAN and might leak their real IP, because the kill switch has not been activated yet. Read the queston How can I block Internet access until after this script runs at boot? in the FAQ below to see how to solve this problem and block Internet access until after this script runs.

The wireguard-go boot script should already be installed at /mnt/data/on_boot.d/20-wireguard.sh if you followed the instructions above, so no further setup is needed to make it run at boot.

OPTIONAL: Note that there is a short period between when the UDMP starts and when this script runs. This means there is a few seconds when the UDMP starts up when your forced clients WILL have access to your WAN and might leak their real IP, because the kill switch has not been activated yet. Read the queston How can I block Internet access until after this script runs at boot? in the FAQ below to see how to solve this problem and block Internet access until after this script runs.

You should already have a run-vpn.sh script created if you followed the OpenConnect instructions above. Simply copy that script to /mnt/data/on_boot.d/99-run-vpn.sh and make sure it has executable permissions.

cp /mnt/data/split-vpn/openconnect/server1/run-vpn.sh /mnt/data/on_boot.d/99-run-vpn.sh
chmod +x /mnt/data/on_boot.d/99-run-vpn.sh

OPTIONAL: Note that there is a short period between when the UDMP starts and when this script runs. This means there is a few seconds when the UDMP starts up when your forced clients WILL have access to your WAN and might leak their real IP, because the kill switch has not been activated yet. Read the queston How can I block Internet access until after this script runs at boot? in the FAQ below to see how to solve this problem and block Internet access until after this script runs.

Create a new file under /mnt/data/on_boot.d/99-run-vpn.sh and fill it with the following.

#!/bin/sh

# Load configuration and bring routes up
cd /mnt/data/split-vpn/nexthop/mycomputer
source ./vpn.conf
/mnt/data/split-vpn/vpn/updown.sh ${DEV} up mycomputer

Run chmod +x /mnt/data/on_boot.d/99-run-vpn.sh to give the script execute permissions.

That's it. Now the VPN rules will be added at every boot. Make sure your VPN computer is set up correctly to always have the VPN on as well.

OPTIONAL: Note that there is a short period between when the UDMP starts and when this script runs. This means there is a few seconds when the UDMP starts up when your forced clients WILL have access to your WAN and might leak their real IP, because the kill switch has not been activated yet. Read the queston How can I block Internet access until after this script runs at boot? in the FAQ below to see how to solve this problem and block Internet access until after this script runs.