Specific Client Overrides Bug with OpenVPN Connect and "Prevent this client from receiving any server-defined client settings."

phil80

Hi,
The error only occurs with OpenVPN Connect client. Using OpenVPN For Android Client works. I found a fix below, but wanted to know if I should file a bug

I setup an OpenVPN server with topology subnet 10.53.53.0/24
I added some client specific overrides and properly configured the DNS...
As soon as we check the option "Prevent this client from receiving any server-defined client settings.", when using OpenVPN Connect client, the client defaults to topology net/30 and fails to connect with below error:

TUN Error: tun_prop_error: ifconfig addresses are not in the same /30 subnet (topology net30)

I tried to fix it by specifying a fixed IP in the client specific overrides:

IPv4 Tunnel Network: 10.53.53.200/24
Advanced:

ifconfig-push 10.53.53.200 255.255.255.0;

Still OpenVPN Connect defaults to topology net30 and errors

The fix was to push the topology subnet in the client overrides
Advanced:

ifconfig-push 10.53.53.200 255.255.255.0;
push "topology subnet"

So, it seems like there is a bug in pfsense when we check "Prevent this client from receiving any server-defined client settings."

The topology should not be excluded !
It seems that specifying it in "IPv4 Tunnel Network" with the /24 mask doesn't properly push the topology and since OpenVPN Connect defaults to net30, it fails. OpenVPN For Android client probably defaults to subnet
Even if not specified in "IPv4 Tunnel Network" to keep the dynamic IP mode, pfSense should use the server network and push the proper topology

phil80

After more testing, it seems that the "Prevent this client from receiving any server-defined client settings." option will in fact prevent any settings, except those defined in the Client Overrides page:

IPv4 Tunnel Network: ifconfig-push client_ip mask
Redirect gateway: push "redirect-gateway def1"
DNS server: push "dhcp-option DNS ip"
NTP server: push "dhcp-option NTP ip"

The problem is that this will break connection for OpenVPN connect which is more strict about the server pushed options than OpenVPN For Android client. The latter will warn about the broken topology and missing gateway, but it will find its way using assumptions based on the netmask for IPv4 Tunnel Network

The below options are needed for OpenVPN Connect and to stop warnings in other clients:

push "route-gateway ip": else all internet traffic will be denied for OpenVPN Connect
push "topology subnet": else, OpenVPN connect will fail. OpenVPN For Android client will warn that the topology is net30 but the domain is subnet, and will assume subnet, so it can connect

The below are optional for a connection success but will not be ported to the client if not set in Advanced section:

push "block-outside-dns": [optional] if it was defined on the server and we want to preserve it
push "register-dns": [optional] if it was defined on the server and we want to preserve it
push "redirect-gateway ipv6": [optional] if it was defined on the server and we want to preserve it
ifconfig-push ip mask: not needed if we specify it in the Client Specific Overrides under "IPv4 Tunnel Network"
push "ping 10": [optional] if it was defined on the server and we want to preserve it
push "ping-restart 60": [optional] if it was defined on the server and we want to preserve it

jkl123

@phil80
Hi, thanks for this post it has helped me get OpenVPN Connect to actually connect! However, after the "topology subnet" option gets things working, applying the "route-gateway ip" it breaks. To be honest with my limited networking knowledge I have been slightly confused as to what I should set my "route-gateway" address too but have tried the ones I think are obvious, 192.168.0.0, 192.168.0.1, 10.8.0.0, 10.8.0.1.
When I look at the logs from the working Tunnelblick I can see a host of gateways being added but not sure how that would translate to the client config.

Tunnelblick log

2022-11-20 10:07:37.427183 /sbin/route add -net 
192.168.0.0 255.255.255.0 255.255.255.0 add net 192.168.0.0: gateway 255.255.255.0

2022-11-20 10:07:37.435777 /sbin/route add -net 10.8.0.0 255.255.255.0 255.255.255.0 add net 10.8.0.0: gateway 255.255.255.0

2022-11-20 10:07:37.443283 /sbin/route add -net 10.8.0.1 255.255.255.0 255.255.255.255 add net 10.8.0.1: gateway 255.255.255.0
2022-11-20 10:07:37.443283 /sbin/route add -net 10.8.0.1 255.255.255.0 255.255.255.255

Am I barking up the wrong tree by using these gateway addresses?

It does work just without a specified GW.

Any pointers would be greatly appreciated.

phil80

@jkl123
the gateway ip is same as your OVPN network interface defined under the server settings
It is the OVPN server interface address