OpenVPN client requests 255.255.255.252 subnet, server refuses anything below /29

Question

I've setup an OpenVPN server with the following network settings:

topology subnet
server 192.168.123.0 255.255.255.0
push "dhcp-option DNS 192.168.123.1"      # DNS to server VPN IP
push "route 192.168.2.0 255.255.255.0"    # Workstations addresses via VPN
keepalive 10 120

So:

• 192.168.2.* = company LAN
• 192.168.123.* = VPN LAN

Linux clients are able to connect, but a Windows 7 system fails with the following error:

There is a problem in your selection of --ifconfig endpoints [local=192.168.123.2, remote=255.255.255.248]. The local and remote VPN endpoints must exist within the same 255.255.255.252 subnet. This is a limitation of --dev tun when used with the TAP-WIN32 driver. Try 'openvpn --show-valid-subnets' ....

This is the full output from the moment the connection initialized:

Thu Jul 01 09:36:55 2010 [server.FOOBAR] Peer Connection Initiated with 84.80.YYY.ZZZ
Thu Jul 01 09:36:56 2010 SENT CONTROL [server.FOOBAR]: 'PUSH_REQUEST' (status=1)
Thu Jul 01 09:36:56 2010 PUSH: Received control message: 'PUSH_REPLY,route 192.168.2.0 255.255.255.252,dhcp-option DNS 192.168.123.1,route-gateway 192.168.123.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.123.2 255.255.255.248'
Thu Jul 01 09:36:56 2010 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: topology (2.0.9)
Thu Jul 01 09:36:56 2010 OPTIONS IMPORT: timers and/or timeouts modified
Thu Jul 01 09:36:56 2010 OPTIONS IMPORT: --ifconfig/up options modified
Thu Jul 01 09:36:56 2010 OPTIONS IMPORT: route options modified< al>Thu Jul 01 09:36:56 2010 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Jul 01 09:36:56 2010 WARNING: Since you are using --dev tun, the second argument to --ifconfig must be an IP address.  You are using something (255.255.255.
248) that looks more like a netmask. (silence this warning with --ifconfig-nowarn)
Thu Jul 01 09:36:56 2010 There is a problem in your selection of --ifconfig endpoints [local=192.168.123.2, remote=255.255.255.248].  The local and remote VPN endpoints must exist within the same 255.255.255.252 subnet.  This is a limitation of --dev tun when used with the TAP-WIN32 driver.  Try 'openvpn --show-valid-subnets' ....

Any attempt to change the server settings to a 252 range results in the following error:

Options error: --server directive when used with --dev tun must define a subnet of 255.255.255.248 (/29) or lower

What server settings do I need to set to make this client connect? The server runs OpenVPN 2.1.1, the Windows 7 client runs OpenVPN 2.0.9 (latest stable from http://openvpn.se)

---

@Evan: This is my client config, not very exciting:

client
dev tun

proto tcp
remote 84.80.203.199 1194
resolv-retry 2
nobind

# Server keys
ca SERVER-ca.crt
tls-auth SERVER-ta.key 1

# Client key
cert SOMEONE.crt
key SOMEONE.key

# Server settings to copy
comp-lzo

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

# Try to preserve some state across restarts.
persist-key
persist-tun

# Verify server
ns-cert-type server

verb 3

;cipher x
;mute 20
;mute-replay-warnings

Solution

I'd start by updating the Windows Vista client to the latest OpenVPN Windows release, particularly 2.1.x line. There were a lot of major changes between 2.0.x and 2.1.x. I'm not saying that's definitely the problem, but I wouldn't want to try it. Especially when the full output from the connection is showing an 'options error' and warnings.

After updating the Windows client, if that doesn't resolve the problem, I'd try running both the server and the client with verb 4 or verb 6 to increase the log verbosity. That might help you pinpoint where the problem is.

Comments

[Spence]

Could you post your client configuration? I'm feeling like there's some "gold" there.

[tomjedrz]

It looks to me that the command to initiate the tunnel is not built correctly.

[vdboor]

Thanks, running the latest OpenVPN release from openvpn.net solved the problems! They also provide certified Windows 7 drivers, which otherwise would be refused by the OS. To get the push routing working, it turned out openvpn had to be started as administrator.