OpenVPN error: --ip-win32 dynamic [offset] : offset is outside of --ifconfig subnet



  • Hi all,
    I am getting this error when connecting to my recently installed OpenVPN setup. Everything is default and just push 4 routes to the client (but that isn't the problem). Usually this is a source (server) config problem where the specified client IPs are outside of the specified subnet (topology subnet) as the error implies (and often fixable by setting up specific CCDs). However I suppose this should be all taken care of by the OpenVPN setup so I am wondering if this is some kind of bug or I missed something. I am running 2.4.4-RELEASE-p3 with the latest openvpn client export. The log of the connection follows:

    Sat Mar 14 19:55:38 2020 OpenVPN 2.4.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 31 2019
    Sat Mar 14 19:55:38 2020 Windows version 6.2 (Windows 8 or greater) 64bit
    Sat Mar 14 19:55:38 2020 library versions: OpenSSL 1.1.0l 10 Sep 2019, LZO 2.10
    Enter Management Password:
    Sat Mar 14 19:55:38 2020 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25343
    Sat Mar 14 19:55:38 2020 Need hold release from management interface, waiting...
    Sat Mar 14 19:55:38 2020 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25343
    Sat Mar 14 19:55:38 2020 MANAGEMENT: CMD 'state on'
    Sat Mar 14 19:55:38 2020 MANAGEMENT: CMD 'log all on'
    Sat Mar 14 19:55:38 2020 MANAGEMENT: CMD 'echo all on'
    Sat Mar 14 19:55:38 2020 MANAGEMENT: CMD 'bytecount 5'
    Sat Mar 14 19:55:38 2020 MANAGEMENT: CMD 'hold off'
    Sat Mar 14 19:55:38 2020 MANAGEMENT: CMD 'hold release'
    Sat Mar 14 19:55:39 2020 MANAGEMENT: CMD 'username "Auth" "username"'
    Sat Mar 14 19:55:39 2020 MANAGEMENT: CMD 'password [...]'
    Sat Mar 14 19:55:39 2020 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
    Sat Mar 14 19:55:39 2020 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
    Sat Mar 14 19:55:39 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
    Sat Mar 14 19:55:39 2020 Socket Buffers: R=[65536->65536] S=[65536->65536]
    Sat Mar 14 19:55:39 2020 UDP link local (bound): [AF_INET][undef]:0
    Sat Mar 14 19:55:39 2020 UDP link remote: [AF_INET]xx.xx.xx.xx:1194
    Sat Mar 14 19:55:39 2020 MANAGEMENT: >STATE:1584212139,WAIT,,,,,,
    Sat Mar 14 19:55:39 2020 MANAGEMENT: >STATE:1584212139,AUTH,,,,,,
    Sat Mar 14 19:55:39 2020 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:1194, sid=d3950fa2 8f5b7b9a
    Sat Mar 14 19:55:39 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
    Sat Mar 14 19:55:39 2020 VERIFY OK: depth=1, CN=internal-ca, C=IT, O=whatever, OU=IT Dep.
    Sat Mar 14 19:55:39 2020 VERIFY KU OK
    Sat Mar 14 19:55:39 2020 Validating certificate extended key usage
    Sat Mar 14 19:55:39 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
    Sat Mar 14 19:55:39 2020 VERIFY EKU OK
    Sat Mar 14 19:55:39 2020 VERIFY X509NAME OK: CN=vpn.whatever.com, C=IT, O=whatever
    Sat Mar 14 19:55:39 2020 VERIFY OK: depth=0, CN=vpn.whatever.com, C=IT, O=whatever
    Sat Mar 14 19:55:40 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
    Sat Mar 14 19:55:40 2020 [vpn.whatever.com] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1194
    Sat Mar 14 19:55:41 2020 MANAGEMENT: >STATE:1584212141,GET_CONFIG,,,,,,
    Sat Mar 14 19:55:41 2020 SENT CONTROL [vpn.whatever.com]: 'PUSH_REQUEST' (status=1)
    Sat Mar 14 19:55:41 2020 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,dhcp-option DOMAIN whatever.com,dhcp-option DNS 192.168.0.1,dhcp-option DNS 192.168.0.2,route-gateway 172.16.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 172.16.0.52 172.16.0.51,peer-id 0,cipher AES-128-GCM'
    Sat Mar 14 19:55:41 2020 OPTIONS IMPORT: timers and/or timeouts modified
    Sat Mar 14 19:55:41 2020 OPTIONS IMPORT: --ifconfig/up options modified
    Sat Mar 14 19:55:41 2020 OPTIONS IMPORT: route options modified
    Sat Mar 14 19:55:41 2020 OPTIONS IMPORT: route-related options modified
    Sat Mar 14 19:55:41 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
    Sat Mar 14 19:55:41 2020 OPTIONS IMPORT: peer-id set
    Sat Mar 14 19:55:41 2020 OPTIONS IMPORT: adjusting link_mtu to 1624
    Sat Mar 14 19:55:41 2020 OPTIONS IMPORT: data channel crypto options modified
    Sat Mar 14 19:55:41 2020 Data Channel: using negotiated cipher 'AES-128-GCM'
    Sat Mar 14 19:55:41 2020 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
    Sat Mar 14 19:55:41 2020 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
    Sat Mar 14 19:55:41 2020 interactive service msg_channel=0
    Sat Mar 14 19:55:41 2020 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 I=20 HWADDR=d0🆎d5:71:f8:a9
    Sat Mar 14 19:55:41 2020 open_tun
    Sat Mar 14 19:55:41 2020 TAP-WIN32 device [Connessione alla rete locale (LAN)] opened: \.\Global{0FFFE127-473A-4BE0-9FB9-746A83E8EF14}.tap
    Sat Mar 14 19:55:41 2020 TAP-Windows Driver Version 9.24
    Sat Mar 14 19:55:41 2020 Set TAP-Windows TUN subnet mode network/local/netmask = 172.16.0.48/172.16.0.52/172.16.0.51 [SUCCEEDED]
    Sat Mar 14 19:55:41 2020 MANAGEMENT: Client disconnected
    Sat Mar 14 19:55:41 2020 ERROR: --ip-win32 dynamic [offset] : offset is outside of --ifconfig subnet
    Sat Mar 14 19:55:41 2020 Exiting due to fatal error

    Thanks for any heads up!


  • LAYER 8 Rebel Alliance

    How about showing your config via screenshots?

    -Rico



  • Hi Rico, the problem actually appears to be related to how the external Windows RADIUS server options are interpreted with versions after 2.1 of pfSense as reported here:
    https://forum.netgate.com/topic/60691/openvpn-win2012-nap-radius-working-great-but-client-doesn-t-get-ip-address

    This is exactly my issue and same config. Setting on the RADIUS server side a specific IP or letting the client offer one still doesn't resolve the offset issue. I can see by the logs that it changes the ifconfig IP range based on what IP I set (as it should) but same error. If I let the client offer the IP it doesn't report error but the ifconfig IP is 255.255.255.255 (ifconfig 255.255.255.255 255.255.255.254) and that doesn't lead to anywhere even if the routes are pushed but the TAP IF doesn't obviously come up.
    I'll try digging further and see - if all fails I'll revert to a local pfSense user/certificate config but would like to use RADIUS.



  • Ok I finally managed to solve the issue: the Windows Server NAP/RADIUS default setup passes a default IP range taken from the default PPP (ex RRAS) template (a 172.16.0.0 range) pushing this to the OpenVPN server and thus to the client which is obviously incompatible. To avoid this you have to edit the relevant Network Policy configuration settings (Policies -> Network Policies) on the Windows Server (2012 R2 upwards) that was created to allow the RADIUS client to authenticate specifying the relevant Windows Security group. From the Settings tab you will see under the "RADIUS Attributes" 2 Attributes: "Framed-Protocol" (PPP) and "Service-Type" (Framed). You must delete these 2 attributes in order to not pass the Windows Server side default template PPP IP ranges. Once this has been done simply click ok and relaunch the VPN connection and it will succeed in bringing up the IF with the correct IP range specified in the OpenVPN server Tunnel IP configuration.


  • Rebel Alliance Developer Netgate

    The RADIUS addresses were being pushed in the old net30 format and not subnet format.

    The fix would be any one of:

    • Switch the server to net30 topology
    • Fix the static address assignments so they are in the right format (single address with a subnet mask matching the server subnet)
    • Remove the static addresses from RADIUS


  • Thanks for the feedback. The MS RADIUS server has no static address specified by default but it does offer the above 172.16.0.0/16 subnet though it's not "user configurable" (I discovered it looking at the logs - there are no such setting in the NAP/RADIUS mmc) unless you probably manually edit the registry (there was no RRAS service previsouly enabled to set them). By removing the 2 above attributes it works as desired using subnet topology without further modifications which is fine for me.

    Cheers


Log in to reply