Can't use OpenVPN as client on NetBSD, route add command fails

Question

I am trying to use OpenVPN as a client under NetBSD using this command:

openvpn --client --config /etc/openvpn/config.ovpn

I am getting the following output and errors:

localhost# openvpn --client --config /etc/openvpn/openvpn.ovpn 
2024-04-26 10:29:35 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2024-04-26 10:29:35 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 
2024-04-26 10:29:35 OpenVPN 2.6.10 x86_64--netbsd [SSL (OpenSSL)] [LZO] [LZ4] [MH/PKTINFO] [AEAD]
2024-04-26 10:29:35 library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10
Enter Auth Username:********
Enter Auth Password:********
2024-04-26 10:32:48 TCP/UDP: Preserving recently used remote address: [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 Socket Buffers: R=[32768->32768] S=[32768->32768]
2024-04-26 10:32:48 Attempting to establish TCP connection with [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 TCP connection established with [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 TCPv4_CLIENT link local: (not bound)
2024-04-26 10:32:48 TCPv4_CLIENT link remote: [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2024-04-26 10:32:48 TLS: Initial packet from [AF_INET]**.191.33.**:1701, sid=0006909e 9b0d208f
2024-04-26 10:32:48 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2024-04-26 10:32:48 VERIFY OK: depth=1, C=US, ST=New York, L=New York, O=Ubiquiti Inc., OU=UniFi_OpenVPN_CA, CN=UniFi_OpenVPN_CA
2024-04-26 10:32:48 VERIFY KU OK
2024-04-26 10:32:48 Validating certificate extended key usage
2024-04-26 10:32:48 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-04-26 10:32:48 VERIFY EKU OK
2024-04-26 10:32:48 VERIFY OK: depth=0, C=US, ST=New York, L=New York, O=Ubiquiti Inc., OU=UniFi_OpenVPN_Server, CN=UniFi_OpenVPN_Server
2024-04-26 10:33:53 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2024-04-26 10:33:53 [UniFi_OpenVPN_Server] Peer Connection Initiated with [AF_INET]**.191.33.**:1701
2024-04-26 10:33:53 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-04-26 10:33:53 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-04-26 10:33:53 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.7.1,route 192.168.4.0 255.255.255.0,route 192.168.2.0 255.255.255.0,route 192.168.1.0 255.255.255.0,route 192.168.3.0 255.255.255.0,route-gateway 192.168.7.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.7.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
2024-04-26 10:33:53 OPTIONS IMPORT: --ifconfig/up options modified
2024-04-26 10:33:53 OPTIONS IMPORT: route options modified
2024-04-26 10:33:53 OPTIONS IMPORT: route-related options modified
2024-04-26 10:33:53 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-04-26 10:33:53 TUN/TAP device /dev/tun0 opened
2024-04-26 10:33:53 /sbin/ifconfig tun0 192.168.7.2 192.168.7.1 mtu 1500 netmask 255.255.255.0 up
2024-04-26 10:33:53 /sbin/route add -net 192.168.7.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.7.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net **.191.33.** 192.168.1.254 -netmask 255.255.255.255
route: writing to routing socket: File exists
add net **.191.33.**: gateway 192.168.1.254: File exists
2024-04-26 10:33:53 ERROR: OpenBSD/NetBSD route add command failed: external program exited with error status: 1
2024-04-26 10:33:53 /sbin/route add -net 0.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 0.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 128.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 128.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.4.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.4.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.2.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.2.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.1.0 192.168.7.1 -netmask 255.255.255.0
route: writing to routing socket: File exists
add net 192.168.1.0: gateway 192.168.7.1: File exists
2024-04-26 10:33:53 ERROR: OpenBSD/NetBSD route add command failed: external program exited with error status: 1
2024-04-26 10:33:53 /sbin/route add -net 192.168.3.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.3.0: gateway 192.168.7.1
2024-04-26 10:33:53 GID set to nogroup
2024-04-26 10:33:53 UID set to nobody
2024-04-26 10:33:53 Initialization Sequence Completed
2024-04-26 10:33:53 Data Channel: cipher 'AES-256-GCM', peer-id: 0, compression: 'lzo'
2024-04-26 10:33:53 Timers: ping 10, ping-restart 60

I have a working internet connection when running OpenVPN as a client, but I can't access any of the machines on the network **.191.33.**, I know I should be able to SSH into 192.168.1.114, but I can't reach that machine through OpenVPN, there are firewall rules in the Ubuiquity box allowing traffic from 192.168.7.* to 192.168.1.* I know this is working, its testet from Mac and PC using the OpenVPN Client, I just can't get it to work on NetBSD

This is my routing table before running OpenVPN:

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

This is my routing table when running OpenVPN:

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
0/1                192.168.7.1        UGS         -        -      -  tun0
default            192.168.1.254      UGS         -        -      -  iwn0
**.191.33.**/32    192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
128/1              192.168.7.1        UGS         -        -      -  tun0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.2/24       192.168.7.1        UGS         -        -      -  tun0
192.168.3/24       192.168.7.1        UGS         -        -      -  tun0
192.168.4/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7.1        192.168.7.2        UH          -        -      -  tun0
192.168.7.2        tun0               UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

This is my routing table after stopping OpenVPN:

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
0/1                192.168.7.1        UGS         -        -      -  tun0
default            192.168.1.254      UGS         -        -      -  iwn0
**.191.33.**/32    192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
128/1              192.168.7.1        UGS         -        -      -  tun0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.2/24       192.168.7.1        UGS         -        -      -  tun0
192.168.3/24       192.168.7.1        UGS         -        -      -  tun0
192.168.4/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7.2        tun0               UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

This is my routing table when i have destroyed tun0:

ifconfig tun0 destroy

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            192.168.1.254      UGS         -        -      -  iwn0
**.191.33.**/32    192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

The route to **.191.33.** is still there when stopping OpenVPN and destroying the tunnel tun0, I don't know if this is expected behaviour.

Update I have checked several computers now, and none of them have the 192.168.1/24 route, its only on the PC running NetBSD, I have tried to delete it, with no success. I have also read a lot of man pages and various other documentation, but I have not come up with anything usefull yet.

OpenVPN Config

client
dev tun
proto tcp
remote **.191.33.** 1701
resolv-retry infinite
nobind

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nogroup

persist-key
persist-tun

auth-user-pass
remote-cert-tls server
cipher AES-256-CBC
comp-lzo
verb 3

auth SHA1
key-direction 1

reneg-sec 0

redirect-gateway def1

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>

Intent

I am trying to connect to a VPN at a remote location, from home. The remote network is protected by a firewall facing the internet, all computers on the network behind the router is accessible, the 192.168.7.* network is standard Ubuiquity and used for VPN clients, I have added a firewall rule to allow traffic from 192.168.7.* to the 192.168.1.* network, this works fine from all computers I have tried it with, Mac, PC, Windows, Linux, MacOS. etc. except a PC running NetBSD.

The network configuration on the PC running NetBSD was performed during installation, and I used the auto-configuration feature, so I have not specified any networks, routes or rules at all. I am able to access the internet when using OpenVPN client, I just cannot access any of the machines on the remote network. So I guess the part I am missing is the routing from 192.168.7.* to 192.168.1.* so I will be able to access computers attached to that network

Answer 1

I have tried it with, Mac, PC, Windows, Linux, MacOS. etc. except a PC running NetBSD

While I'm not familiar with NetBSD, but based on the route table you have pasted, and the man page of NetBSD's route command online, it seems that the OS does not support something called route metric, which is basically a number that indicates a route's precedence.

In modern Linux, and probably Windows and macOS as well, it is possible for you to have routes with the same destination (note that destination means the IP range / block that is covered by the route, not the "nexthop" or anything equivalent) in the same route table. (And let's call such route "duplicate routes", even when they are not really "duplicates".) The route with the lowest metric value (highest precedence) would be used for traffics that has a destination that is covered by the routes.

(In fact, in at least Linux, IIRC, you are not forbidden to have "duplicate routes" that have same metric values, including but not limited to the lowest value 0, which can make the value hidden in at least outputs of some related commands. I don't know what exact behavior / policy that would result in though.)

So from what we / I can tell from the outputs / logs you have pasted, NetBSD does not allow duplicate routes and/or route metric. As a result, a route you need for a remote site / host, namely 192.168.1.0/24 (192.168.1/24 is just another form of representation of that), which happens to be the IP subnet used in the local LAN the NetBSD host is in, is not added, which is why you can't access 192.168.1.114 (the one on the remote side).

As a workaround, you can add overriding routes that are not "duplicates". For example, if 192.168.1.114 is the only 192.168.1.0/24 host you need to access:

route add -host 192.168.1.114 192.168.7.1

or, if you want to access as many 192.168.1.0/24 hosts on the remote side as possible:

route add -net 192.168.1.0 192.168.7.1 -netmask 255.255.255.128
route add -net 192.168.1.128 192.168.7.1 -netmask 255.255.255.128

(which basically split a 192.168.1.0/24 route into two halves, so that you can have an "effectively duplicate" of higher precedence. If you want to understand the rationale of such override, you would need to dive into L3 networking concepts like VLSM, prefix length and so on, and/or how routing decision is made in general).

If you want these commands to be automated by OpenVPN, you can have equivalent route options in your client conf/ovpn file. (I'm too lazy to give the exact syntax here, but you pretty much just need to stuff in the same sets of "numbers" there. Consult the OpenVPN manual for details.)

With such an approach / workaround, you do NOT need to attempt to get rid of the "original" 192.168.1.0/24 route, since it would be effectively made "dormant".

(Generally speaking, you need to make sure a route specifically for the LAN gateway has been added before you take the approach. In the case of DHCP, often, like in your case apparently, but not necessarily AFAIK, such route is advertised by the DHCP server and/or configured by the DHCP client, given the fact that it's sort of a redundancy to the prefix route in typical network setup.)

Do note that regardless of how you do it, since the destination (192.168.1.0/24) is still a "conflict" between your LAN and the remote site, therefore, if you choose to have route for / obtain access to the remote site, or just one of the hosts like 192.168.1.114, you cannot access the host(s) with the same IP on the local side, not until you remove the added route(s), either by just removing them or destroying the tun interface.

Yet it is more or less impossible to have access to a remote host that is assigned with the IP of your LAN gateway (namely 192.168.1.254 in your case) or the IP of this client host itself (namely 192.168.1.68, which may change to another one if we are talking about DHCP here).

---

The ERROR: OpenBSD/NetBSD route add command failed lines you see can be somewhat considered harmless. As I mentioned in the command, since/if these errors does not stop OpenVPN from successfully establishing the connection / setup, all you need is to "compensate" what have failed / were missed, namely in your case to add alternate / overriding routes for 192.168.1.0/24 manually. (Although I can't tell for sure whether or not a "non-error-free" connection is the reason that OpenVPN does not revert its operations when the connection is being torn down.)

(The one for **.191.33.** is also harmless because it's just a consequence of a "real" duplicate route for the VPN's "remote address" being found in the route table, due to the fact that your OpenVPN program somehow does not revert stuff it did when it is stopped. I'm pretty sure you won't be seeing it if say, you were connecting for the first time after a reboot. And obviously, nothing you need to "compensate" here. If you want to know why such route is being added, check out the redirect-gateway option in the OpenVPN manual. It's basically for a similar reason I mentioned above for the LAN gateway route.)

You only "need" a pull filter if what you are trying to accomplish is to prevent certain route being pushed by the server from stopping you from accessing hosts on the local side, or, more precisely, via your existing / physical interface. (Certainly that means you don't mind "losing" access to hosts on the remote side that are in the conflicting subnet.) But in your case, NetBSD more or less "did it for you" already, whether you want it or not.

---

I do think you want to find out why in your case OpenVPN does not revert its "manipulations" (including but not limited to adding the tun interface, i.e. removing it for reversion) when being stop, like whether you are / NetBSD is stopping it in a wrong way or so (e.g. SIGKILL?). I myself have no idea to contribute with that regard though.

Answer 2

This is now a rewrite based on new information from the OP posted as comments to this answer, updates to the question, information pointed out by @TomYan, as well as my own investigations into the source code of OpenVPN.

As a preface let me state it has been many years since I last used OpenVPN. However fundamentally all the OpenVPN client is doing is authenticating connection then configuring a local tunnel and routes to pass traffic via that tunnel, and then it passes packets to/from the userland endpoint of that tunnel via an encrypted connection from/to the remote OpenVPN server.

I'm also assuming that the "auto-configuration" feature you used during NetBSD installation is the same one I would associate with "use DHCP to configure the network interface", and that you have configured it to use the same, WiFi router and DHCP server as your other local computers are using.

---

You state in a comment below:

My LAN is very simple, 192.168.1.1 gateway and router, issuing IPv4 addresses using DHCP, and all computers and devices are connected using WiFi.

According to the logs you show that is in conflict with the network routes being pushed by the remote OpenVPN server.

You cannot have two identically prefixed IPv4 subnets in different places and then expect to be able to communicate between them.

So, first off you must reconfigure your local router to use a different subnet. That can be any of the private RFC 1918 networks, except those being pushed by your remote OpenVPN server. I would avoid anything with the 192.168 prefix, since that seems to be a favourite of the remote OpenVPN server.

Note you should not have to put your WiFi router in bridge mode. Just change its LAN address and the subnet it is providing.

Remember to reboot all your local computers after making the subnet change, and test that they continue to work (with and without the VPN) as well.

If you cannot change the subnet of your local WiFi network then (if you want to use that OpenVPN server) you're stuck with having to put another router (with NAT) and WiFi gateway in front of the existing one and set it up so that it NATs to a new unique subnet of your choice. Such a config would not be ideal though and would be unreliable!

---

Secondly your local OpenVPN client configuration has the following line:

redirect-gateway def1

The current way the OpenVPN client attempts to implement this, as shown by the log entries below (and confirmed by my reading of the code), is probably incompatible with NetBSD, or any other system with BSD networking code:

2024-04-26 10:33:53 /sbin/route add -net 0.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 0.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 128.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 128.0.0.0: gateway 192.168.7.1

These route entries (probably) won't have the desired effect on any BSD system (and if they do it is by accident, not design). The OpenVPN client has not been properly ported to BSD yet.

So also I would strongly recommend removing the redirect-gateway def1 line from your OpenVPN client config, and replace it with:

pull-filter ignore redirect-gateway

Also as a side note I would say that in my opinion redirecting all traffic through the VPN is rarely ever the best way to set things up.

---

Finally you say that none of your other computers have a route to 192.168.1/24. That sounds at face value to be impossible and is quite confusing. Either those other computers are not on the same LAN as the NetBSD machine, or they are somehow not using the same DHCP server on that LAN, and/or they are not connecting to the same OpenVPN server. One way or another they should all have a 192.168.1/24 route, at least when their OpenVPN clients are running and connected.

Are you sure all your local computers really are connected to the same LAN via the same WiFi router and DHCP server? Disable OpenVPN on one of them and reboot it without starting the OpenVPN client, and check again how its network interface is configured.