Richard Bucker

OpenBSD VPN DNS

Posted at — Nov 8, 2021

In my lab I have two network segments. The first is dedicated to Wifi and the second is wired. The Wifi network is for IoT, phones, laptops, iPads and quests. The wired segment is strictly for my servers and certain types of remote connections. The challenge is that when I’m working on the wired network and connected via VPN to a remote site that I have to decide whether to honor the server configuration, make my own routes and nameserver resolution and so on. Certain machines in my lab need active connections to my local LAN and/or I do not want to share all my network activity with a remote site’s operation staff.

not many remote customers are going to support my entire technology requirements in order to get exclusive use. And then that itself creates productivity challenges.

I’m going to refer to OpenVPN because it’s particularly quirky. L2TP+IPSec behaves somewhat similarly but is sort of untested in this configuration.

Use Case 1. I have a NUC that is connected to my Wifi and Wired network. It’s running default OpenBSD 7.0 settings and is using DHCP when connecting to both networks. My Wifi network is not assigned a domain name as the router does not seem to support that and the wired network does.

cat /var/db/dhcpleased/em0
cat /var/db/dhcpleased/iwm0

By default OpenBSD is running resolvd and so /etc/resolv.conf is configured accortingly. In my case the resolvd inserts one nameserver line for each network. I have not been able to determine if there is a bias whether it is alphabetical by domain, device, or random. However, the first name server is going to get ALL the DNS requests unless it’s not available. Therefore, if the first nameserver is my Wifi network then I’ll never resolve a hostname for my wired LAN.

Now if I’m connected to a VPN I’ll have 3 network connections. If I accept the routes as provided I have 192.168.1.0/24 for my Wifi, 192.168.2.0/24 for my wired, and 172.16-19.0.0/?? and 192.168.99.0/24 for my VPN. Here are some challenges:

Network-Manager can update /etc/resolv.conf and it does do the magic but not all Linux OS' support NMCLI. And specifically since I’m talking about OpenBSD that’s not likely there either. So this is a mess and there is no seamless way to go about it. Either they will capture too much or too little.

In order to get this to work in my OpenBSD environment:

And now it will resolve in the correct location.