pfSense

We're aware of this, but it's an OpenVPN bug, not a bug in our code. As you see, the variables are unpopulated even when they should be.

When set not to pull routes, or when the server does not push any routes, OpenVPN cannot determine the remote gateway properly and sets the gateway to its own IP address. In most cases this is harmless, however, because that route just nudges traffic to enter OpenVPN and OpenVPN makes its own routing decisions later. In the non-DCO case this works like it always has, but in the DCO case it can be trickier, though it should work properly on the most recent builds.

One workaround is to allow the client to pull routes (uncheck Don't pull routes) and check Don't add/remove routes instead. That will let OpenVPN find the remote gateway but won't affect the contents of the routing table. This works for the case when the client is opting not to accept routes but it doesn't help when the server doesn't push any routes. Making the server push at least one 'dummy' route to a meaningless network in addition to these client settings will work around it, though.

The code in /usr/local/sbin/ovpn-linkup tries to check route_vpn_gateway and ifconfig_remote but they are both empty so it falls back to ifconfig_local. Looking at the environment variables available there aren't any that have the remote address in there, despite the fact that it's actually on the interface.

Using ifconfig to get the remote address is not a viable long term fix.

There is an OpenVPN bug entry that suggests the empty/unset ifconfig_remote is due to subnet topology, which may be true, though it doesn't explain why it's actually used on the interface but not present in the environment.

There is a separate OpenVPN bug entry about the lack of route_vpn_gateway when no routes are pushed/pulled.

This really needs to be fixed upstream in OpenVPN rather than trying to hack around it locally.