OpenVPN and overeager DHCP [solved]

[miket]

I've been having lots of "fun" setting up remote access for my brother's shiny new NAS. Though it is possible to set up a VPN server in a Docker container on the NAS, it would make me nervous to set up such a busy internet-exposed endpoint on the same machine that hosts his files. The only other machine consistently available on his network is the wireless router. If that router would let me install OpenWRT, I'd sure do it--but it's locked down. (My brother likes the router because it gives him good coverage all over his house.) It does include an OpenVPN server, so that's what I have to work with.

To test things, I set up OpenVPN on my own OpenWRT-based router and talk to it with OpenVPN on one of my Gentoo laptops. Communication works fine, but the setup is not what I expected: 1. it did not route all my laptop's traffic over the VPN, and 2. it did not let me look up addresses on my remote network. As for point 1, I see that that all those ads for commercial VPN providers lulled me into thinking that OpenVPN is also supposed to work that way. It was not immediately clear, but now I know that OpenVPN ordinarily leaves the existing default route alone as it provisions a tunneled route to the addresses on the remote network. Knowing that simplifies my life because that's just the configuration I wanted.

My problem is that /etc/resolv.conf does not change when I start the openvpn service (I'm using OpenRC). After some digging, I see that openvpn is configured to run /etc/openvpn/up.sh when the connection handshake finishes. Here are what are evidently the lines of happiness in that script:

Code: Select all

                # Preserve the existing resolv.conf
                if [ -e /etc/resolv.conf ] ; then
                        cp /etc/resolv.conf /etc/resolv.conf-"${dev}".sv
                fi
                printf "${DNS}" > /etc/resolv.conf
                chmod 644 /etc/resolv.conf

To find if the script reached these lines and do what they look like they should do, I added

Code: Select all

cp -p /etc/resolv.conf /etc/resolv.conf.snapshot

right after that block and restarted the service. What I found is that the new /etc/resolv.conf was written correctly:

Code: Select all

$ cat /etc/resolv.conf.snapshot
# Generated by openvpn for interface tun0
domain lan.example.com
nameserver 192.168.100.1

but was almost immediately overwritten. See how the new /resolv.conf was clobbered in less than 0.05 seconds:

Code: Select all

$ ls --full-time /etc/resolv.conf*
-rw-r--r-- 1 root root 209 2025-11-11 13:33:12.570588034 -0500 /etc/resolv.conf
-rw-r--r-- 1 root root  94 2025-11-11 13:33:12.523586817 -0500 /etc/resolv.conf.snapshot
-rw-r--r-- 1 root root 209 2025-11-11 13:33:12.522586791 -0500 /etc/resolv.conf-tun0.sv

Um, that's annoying. If I copy /etc/resolv.conf.snapshot back onto /etc/resolv.conf, I can resolve addresses on the remote network--for a brief window that may last nine minutes if I'm lucky. After that, I'm back to the /etc/resolv.conf that dhcpcd set for the laptop when I connected to the wireless network.

I doubt that this is normal for VPN users. Is there something that would trigger dhcpcd to update /etc/resolv.conf and, if so, a way to stop doing that while the VPN is active?

[John R. Graham]

What does the clobbered /etc/resolv.conf look like?

Typically dhcpcd's job should be long done by the time that you connect to the VPN, so I'm hoping for some evidence from the clobbered file.

- John

[miket]

What does the clobbered /etc/resolv.conf look like?

Typically dhcpcd's job should be long done by the time that you connect to the VPN, so I'm hoping for some evidence from the clobbered file.

- John

Before connecting:

Code: Select all

# Generated by dhcpcd from wlan0.dhcp, wlan0.dhcp6, wlan0.ra
# /etc/resolv.conf.head can replace this line
domain attlocal.net
nameserver 192.168.1.254
nameserver 2600:1700:1602:700::1
# /etc/resolv.conf.tail can replace this line

After connecting:

Code: Select all

# Generated by dhcpcd from wlan0.dhcp, wlan0.dhcp6, wlan0.ra
# /etc/resolv.conf.head can replace this line
domain attlocal.net
nameserver 192.168.1.254
nameserver 2600:1700:1602:700::1
# /etc/resolv.conf.tail can replace this line

And as an aid to relieving any eystrain in comparing the two:

Code: Select all

#Before conncting
$ md5sum /etc/resolv.conf
7045570f5849fd7a3441a12b2cd1d8b1  /etc/resolv.conf

#After connecting
$ md5sum /etc/resolv.conf
7045570f5849fd7a3441a12b2cd1d8b1  /etc/resolv.conf

One other curious thing to note: I logged into f.g.o to start this message and paste in the contents of the file. Starting the VPN logged me out, so I had to log in again to finish this post.

[grknight]

I would suggest installing net-dns/openresolv or, if using systemd, enabling the resolvconf USE on sys-apps/systemd.

dhcpcd will look for and use resolvconf if present.

Then, your OpenVPN scripts can use the resolvconf command to update /etc/resolv.conf without conflict like in this article.

Edit: See also this example OpenVPN script

[John R. Graham]

Ah. That explains why my DHCP doesn't misbehave on my laptop with openvpn. I had it installed before I started using openvpn.

- John

[miket]

I would suggest installing net-dns/openresolv or, if using systemd, enabling the resolvconf USE on sys-apps/systemd.

dhcpcd will look for and use resolvconf if present.

Then, your OpenVPN scripts can use the resolvconf command to update /etc/resolv.conf without conflict like in this article.

Edit: See also this example OpenVPN script

Ah, yes, that works. Thank you, thank you!

I drew a good bit confidence when I noticed that openresolv is another of Roy Marples' projects. Indeed, I had seen hooks in the Gentoo-specific openvpn scripts that would use /sbin/resolvconf if present and then wondered what would install that binary. Now I know--it's from openresolv.

My openvpn problems went away once openresolv was merged on my system. There was nothing to start, and nothing to configure. There was a time or two I was in a really long openvpn session when I lost name resolution on the remote network after (evidently) something timed out, but since this happened so rarely--not nearly often enough to characterize--I wasn't worried about it. Besides, it was easy to fix the situation by restarting the vpn instance.

I wanted to go a few days with openresolv over multiple network changes before reporting back on the forum. I'm still quite happy with it. I have had it give me no trouble at all in operations where no VPN was connected. I can now mark the case as solved.