OpenVPN inside a network namespace appears to ignore the error

Likeethimp

I’m running an OpenVPN client inside a Linux network namespace with the following command:
ip netns exec vpn openvpn --fast-io --config /etc/openvpn/OpenVPN-Configs/Random-TCP.ovpn
The connection normally works without any issues for quite a while, but occasionally OpenVPN fails to resolve the VPN server hostname and reports an error similar to:
RESOLVE: Cannot resolve host address: XXXXXXX:XXXX (Temporary failure in name resolution)
I investigated the issue with strace and noticed that OpenVPN is opening the system /etc/resolv.conf. The file points to the systemd-resolved stub resolver and contains 127.0.0.1 as the DNS address, which obviously isn’t useful from inside this namespace.
What confuses me is that I already have a namespace-specific resolver configuration at:
/etc/netns/vpn/resolv.conf
It contains the DNS servers I expect the namespace to use. Running:
ip netns exec vpn cat /etc/resolv.conf
correctly shows the contents of /etc/netns/vpn/resolv.conf.
DNS also works normally for other applications running inside the vpn namespace.
The OpenVPN process itself is definitely still inside the namespace. For example:
ip netns identify <OPENVPN_PID>
returns:
vpn
The interesting part is that /etc/resolv.conf on the host is a symlink:
/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
Yet strace shows OpenVPN directly opening /etc/resolv.conf and reading the host resolver configuration.

So I’m trying to understand what could cause this behavior. Does OpenVPN perform DNS resolution in a way that bypasses the mount performed by ip netns exec, or is there some interaction with systemd-resolved or OpenVPN's resolver implementation that I’m missing?
Could this be an OpenVPN bug, or is there a specific configuration needed to make OpenVPN consistently use the namespace-specific resolv.conf?
Any pointers on how to diagnose or work around this would be greatly appreciated.

Mohammad Montazeri

One distinction worth checking is the running process’s mount namespace, not only its network namespace. The ip-netns manual explains that ip netns exec creates a mount namespace for the per-namespace configuration files, while ip netns identify reports the network namespace. So the latter does not establish which resolver-file mount the OpenVPN process currently sees: https://man7.org/linux/man-pages/man8/ip-netns.8.html

Could you record the actual OpenVPN PID and compare its /proc/<PID>/ns/net and /proc/<PID>/ns/mnt links while resolution works and when it fails? Also capture the resolver file as seen by that running process, and whether the PID changes or a service/wrapper restarts it between the two observations. A new ip netns exec vpn cat /etc/resolv.conf tests a newly launched process, so preserving evidence from the failing PID would help separate a launch/mount-view difference from an OpenVPN resolver bug. Please redact internal hostnames and resolver addresses; no configuration or symlink changes are needed for that first comparison.

AI-assisted reply; I work on a VPN service.

Likeethimp

I’ve seen similar issues with OpenVPN running inside network namespaces. Since ip netns exec vpn cat /etc/resolv.conf shows the namespace-specific file and other applications resolve DNS correctly
I’ve seen similar issues with OpenVPN running inside network namespaces. Since ip netns exec vpn cat /etc/resolv.conf shows the namespace-specific file and other applications resolve DNS correctly