Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 2 Posters 5.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      phil80
      last edited by 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
      1 Reply Last reply Reply Quote 0
      • P
        phil80
        last edited by

        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
        1 Reply Last reply Reply Quote 0
        • J
          jkl123
          last edited by

          @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.

          P 1 Reply Last reply Reply Quote 0
          • P
            phil80 @jkl123
            last edited by

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

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.