Introduction
Introduction Statistics Contact Development Disclaimer Help
Title: OpenVPN on OpenBSD in its own rdomain to prevent data leak
Author: Solène
Date: 16 December 2021
Tags: openbsd openvpn security
Description: This article explains how to prevent programs to access
the Internet through a non VPN interface.
# Introduction
Today I will explain how to establish an OpenVPN tunnel through a
dedicated rdomain to only expose the VPN tunnel as an available
interface, preventing data leak outside the VPN (and may induce privacy
issues). I did the same recently for WireGuard tunnels, but it had an
integrated mechanism for this.
Let's reuse the network diagram from the WireGuard text to explain:
```network diagram in text
+-------------+
| server | tun0 remote peer
| |---------------+
+-------------+ |
| public IP |
| 1.2.3.4 |
| |
| |
/\/\/\/\/\/\/\ |OpenVPN
| internet | |VPN
\/\/\/\/\/\/\/ |
| |
| |
|rdomain 1 |
+-------------+ |
| computer |---------------+
+-------------+ tun0
rdomain 0 (default)
```
We have our computer and have been provided an OpenVPN configuration
file, we want to establish the OpenVPN toward the server 1.2.3.4 using
rdomain 1. We will set our network interfaces into rdomain 1 so when
the VPN is NOT up, we won't be able to connect to the Internet (without
the VPN).
# Network configuration
Add "rdomain 1" to your network interfaces configuration file like
"/etc/hostname.trunk0" if you use a trunk interface to aggregate
Ethernet/Wi-Fi interfaces into an automatic fail over trunk, or in each
interface you are supposed to use regularly. I suppose this setup is
mostly interesting for wireless users.
Create a "/etc/hostname.tun0" file that will be used to prepare the
tun0 interface for OpenVPN, add "rdomain 0" to the file, this will be
enough to create the tun0 interface at startup. (Note that the keyword
"up" would work too, but if you edit your files I find it easier to
understand the rdomains of each interface).
Run "sh /etc/netstart" as root to apply changes done to the files, you
should have your network interfaces in rdomain 1 now.
# OpenVPN configuration
From here, I assume your OpenVPN configuration works. The OpenVPN
client/server setup is out of the scope of this text.
We will use rcctl to ensure openvpn service is enabled (if it's already
enabled this is not an issue), then we will configure it to use rtable
1 to run, this mean it will connect through the interfaces in the
rdomain 1.
If your OpenVPN configuration runs a script to set up the route(s)
(through "up /etc/something..." directive in the configuration file),
you will have to by add parameter -T0 to the command route in the
script. This is important because openvpn will run in rdomain 1 so
calls to "route" will apply to routing table 1, so you must change the
route command to apply the changes in routing table 0.
```instructions
rcctl enable openvpn
rcctl set openvpn rtable 1
rcctl restart openvpn
```
Now, you should have your tun0 interface in rdomain 0, being the
default route and the other interfaces in rdomain 1.
If you run any network program it will go through the VPN, if the VPN
is down, the programs won't connect to the Internet (which is the
wanted behavior here).
# Conclusion
The rdomain and routing tables concepts are powerful tools, but they
are not always easy to grasp, especially in a context of a VPN mixing
both (one for connectivity and one for the tunnel). People using VPN
certainly want to prevent their programs to not go through the VPN and
this setup is absolutely effective in that task.
You are viewing proxied material from dataswamp.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.