Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1302 closed Bug / Defect (wontfix)

Server gets 2nd IP from /30 range instead of 1st IP in /30 range

Reported by: novaflash Owned by:
Priority: minor Milestone:
Component: Generic / unclassified Version: OpenVPN 2.5.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: ipwin32 net30 tap
Cc: tct

Description

(relaying this for an interested party)

We have things set up so that the OpenVPN server assigns an IP from a /30 range. The VPN client’s static IP is the 2nd IP from that /30 range.

We expect to see the server take the first IP, and the client the second IP.

But somehow 2nd IP is assigned to server, which overlaps with client IP.

2020-07-16 20:54:19 ERROR: There is a clash between the --ifconfig local address and the internal DHCP server address -- both are set to 100.96.1.34 -- please use the --ip-win32 dynamic option to choose a different free address from the --ifconfig subnet for the internal DHCP server
2020-07-16 20:54:19 Exiting due to fatal error

Checked on official release 2.4.9 and also on a temporary build that Mattock posted on the openvpn-devel list with 2.5.0 for Windows. We experience this problem on Windows.

Change History (14)

comment:1 Changed 4 years ago by Gert Döring

more log files are needed, especially the PUSH_REPLY.

But it's likely that /30 does not work on windows with 2.4 due to the hackery with the virtual DHCP server. With 2.5, using --dev-type wintun, it should work fine.

comment:2 Changed 4 years ago by novaflash

Yeah, sorry about that, I was just rushed to get some information to dazo while he was still in the community meeting with you guys, and this was all I got handed to me. Also, I had the impression that a colleague of mine had just worked on this very recently, so this might have been enough for you guys to trigger an "aha, we have a patch for that" reaction. But I guess not :)

So now, a bit more info.

When I connect I get this push-reply:
100.96.1.33,ifconfig 100.96.1.34 255.255.255.252,ifconfig-ipv6 fd:0:0:8102::2/126 fd:0:0:8102::1,client-ip 82.161.238.238,ping 8,ping-restart 40,reneg-sec 3600,cipher AES-256-GCM,compress stub-v2,peer-id 489,topology subnet,explicit-exit-notify,route 100.96.0.0 255.224.0.0,route-ipv6 fd:0:0:8000::/49,route 100.80.0.0 255.240.0.0,route-ipv6 fd:0:0:4000::/50,route 1.2.3.0 255.255.255.0,route 2.3.4.0 255.255.255.0,dhcp-option DNS 100.96.1.33,auth-tokenSESS_ID,auth-token-user beepboopcodehere'

On Debian 10 with OpenVPN 2.4.7 I get the proper IP 100.96.1.34 and there is no issue.

On Windows 10 with OpenVPN GUI with OpenVPN 2.4.9 and 2.5.0 with TAP driver I get no IP and an error:
Fri Jul 17 02:20:55 2020 TAP-Windows Driver Version 9.24
Fri Jul 17 02:20:55 2020 Set TAP-Windows TUN subnet mode network/local/netmask = 100.96.1.32/100.96.1.34/255.255.255.252 [SUCCEEDED]
Fri Jul 17 02:20:55 2020 MANAGEMENT: Client disconnected
Fri Jul 17 02:20:55 2020 ERROR: There is a clash between the --ifconfig local address and the internal DHCP server address -- both are set to 100.96.1.34 -- please use the --ip-win32 dynamic option to choose a different free address from the --ifconfig subnet for the internal DHCP server
Fri Jul 17 02:20:55 2020 Exiting due to fatal error

On Windows 10 with OpenVPN GUI with OpenVPN 2.5.0 with wintun driver it works fine.

So yes, it looks like when TAP driver is used we have this issue.

However, we use the TAP driver in OpenVPN Connect v3.1.3 and OpenVPN Connect v2.7.1.x with OpenVPN3 core, and there it works fine.

So why can TAP work fine with /30 when used with OpenVPN3 core, but not with OpenVPN2 core? Still smells like a bug to me.

Last edited 4 years ago by novaflash (previous) (diff)

comment:3 Changed 4 years ago by novaflash

Also just wanted to say that priority isn't very high for us right now because wintun works and we are moving towards wintun on the OpenVPN Connect v3.2.0 app too now.

comment:4 Changed 4 years ago by stipa

I agree with Gert. Code-wise problem seems to be here:

if (offset < 0)
{
    dsa = (local | (~netmask)) + offset;
}
else
{
    dsa = (local & netmask) + offset;
}

if (dsa == local)
{
    msg(M_FATAL, "ERROR: There is a clash between the --ifconfig local address and the internal DHCP server address -- both are set to %s -- please use the --ip-win32 dynamic option to choose a different free address from the --ifconfig subnet for the internal DHCP server", print_in_addr_t(dsa, 0, &gc));
}

By default offset is -1, so in your case you get dsa same as local:

>>> local = int(ipaddress.IPv4Address("100.96.1.34"))
>>> netmask = int(ipaddress.IPv4Address("255.255.255.252"))
>>> dsa = local | ~netmask
>>> str(ipaddress.IPv4Address(dsa & 0xffffffff - 1))
'100.96.1.34'

Could you try to set offset to 0 in client config?

ip-win32 dynamic 0

Alternatively you could ipapi/netsh instead (what wintun does), for example:

ip-win32 ipapi
Last edited 4 years ago by stipa (previous) (diff)

comment:5 Changed 4 years ago by tct

Cc: tct added

comment:6 Changed 4 years ago by novaflash

Thanks for looking into this guys. And yeah, I had no doubt about Gert's statements, just trying to dive into this issue a bit and come to some sensible conclusion.

Results of testing:

ip-win32 dynamic -2 - this works.

Tue Jul 21 13:39:14 2020 Set TAP-Windows TUN subnet mode network/local/netmask = 100.96.1.32/100.96.1.34/255.255.255.252 [SUCCEEDED]Tue Jul 21 13:39:14 2020 Notified TAP-Windows driver to set a DHCP IP/netmask of 100.96.1.34/255.255.255.252 on interface {ADC72D04-150D-4B95-95C3-21B643DE4C82} [DHCP-serv: 100.96.1.33, lease-time: 31536000]

ip-win32 ipapi - this does not work and looks to be a permissions problem, so likely requires admin rights to even work, which is not ideal.

Tue Jul 21 13:34:36 2020 ERROR: AddIPAddress 100.96.1.34/255.255.255.252 failed on interface {ADC72D04-150D-4B95-95C3-21B643DE4C82}, index=4, status=5 (windows error:'Access is denied. ') -- I am having trouble using the Windows 'IP helper API' to automatically set the IP address -- consider using other --ip-win32 methods (not 'ipapi')

ip-win32 netsh - mixed results - the IP assignment seems to somewhat work at first fails in a later step.

ue Jul 21 13:37:00 2020 Set TAP-Windows TUN subnet mode network/local/netmask = 100.96.1.32/100.96.1.34/255.255.255.252 [SUCCEEDED]
Tue Jul 21 13:37:00 2020 MANAGEMENT: >STATE:1595327820,ASSIGN_IP,,100.96.1.34,,,,Tue Jul 21 13:37:01 2020 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet 2 static 100.96.1.34 255.255.255.252Tue Jul 21 13:37:01 2020 ERROR: netsh command failed: returned error code 1Tue Jul 21 13:37:06 2020 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet 2 static 100.96.1.34 255.255.255.252Tue Jul 21 13:37:06 2020 ERROR: netsh command failed: returned error code 1Tue Jul 21 13:37:11 2020 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet 2 static 100.96.1.34 255.255.255.252Tue Jul 21 13:37:11 2020 ERROR: netsh command failed: returned error code 1Tue Jul 21 13:37:16 2020 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet 2 static 100.96.1.34 255.255.255.252Tue Jul 21 13:37:16 2020 ERROR: netsh command failed: returned error code 1Tue Jul 21 13:37:20 2020 MANAGEMENT: Client disconnectedTue Jul 21 13:37:20 2020 NETSH: command failedTue Jul 21 13:37:20 2020 Exiting due to fatal error

Last edited 4 years ago by novaflash (previous) (diff)

comment:7 Changed 4 years ago by novaflash

Just noticed that stipa changed the instruction to try from offset -2 to offset 0. It also works with offset 0. So that's cool.

Adding additional information:

This was tried on OpenVPN GUI 2.4.9 and on temp build Samuli posted on the openvpn-devel list for OpenVPN GUI 2.5.0, all on Windows 10. These logs come from OpenVPN GUI and the connections are run through OpenVPN GUI. Just to remove any doubt in that area.

OpenVPN GUI 2.4.9 with 'ip-win32 dynamic' option being used:
https://crashed.computer/1302/dynamic_2.4.9.log

OpenVPN GUI 2.4.9 with 'ip-win32 ipapi' option being used:
https://crashed.computer/1302/ipapi_2.4.9.log

OpenVPN GUI 2.4.9 with 'ip-win32 netsh' option being used:
https://crashed.computer/1302/netsh_2.4.9.log

OpenVPN GUI 2.5.0 with 'ip-win32 dynamic' option being used:
https://crashed.computer/1302/dynamic_2.5.0.log

OpenVPN GUI 2.5.0 with 'ip-win32 ipapi' option being used:
https://crashed.computer/1302/ipapi_2.5.0.log

OpenVPN GUI 2.5.0 with 'ip-win32 netsh' option being used:
https://crashed.computer/1302/netsh_2.5.0.log

Version 0, edited 4 years ago by novaflash (next)

comment:8 Changed 4 years ago by Gert Döring

This is not "2.5.0", so please do not call it as such - it's some git master snapshot which is likely to see a few more bugfixes before being 2.5.0.

Anyway. Looking at the code, it is somewhat convoluted, but the combination of "ip-win32 netsh" together with having the iservice around should actually not try to run netsh.exe but run the iservice address service instead.

Your log suggest that you have no iservice and run the GUI as unprivileged user - in this case, only DHCP will work, and only for IPv4. As support would say "this is not a recommended or supported configuration".

comment:9 Changed 4 years ago by novaflash

I call it 2.5.0 because the filename and version number in the binary calls it that, and as I said, it's a temp build, and not a stable release, since that's not even out yet. I am not trying to misrepresent the situation here. I explained that it is a temp build we're using. But it is the only version I have that does wintun, so that's what we're using to test, along with 2.4.9 stable release.

Regarding the interactive service, the odd thing here is that the service is installed and running. OpenVPN GUI is installed with default settings, and default settings install it and use it, as far as I know. But if the logs show it wasn't used, I don't know what's going on, I can't answer that one.

Regarding the issue in general, we discussed here and what we ended up with is that we know that this logic in OpenVPN2 is not as good as the smarter implementation that exists in OpenVPN3. But since it's pretty hard to get this configuration anyways and wintun works fine, and considering everything altogether, we can live with a workaround of pushing "ip-win32 dynamic 0" from the server side to workaround this issue.

So I think we can consider this as a "won't fix" and close it, and we will use the workaround.

comment:10 Changed 4 years ago by Selva Nair

I had a patch to change the default offset to 0, but then we decided to just fix the manpage and keep the offset at -1, for wahetever reason (commit 251cc8f20..). I still believe 0 is a better value, but well.... As already figured, one can use a custom offset parameter for ip-win32 to get this to work.

comment:11 Changed 4 years ago by novaflash

Keywords: ipwin32 net30 tap added; oh shit removed
Priority: majorminor
Resolution: wontfix
Status: newclosed

comment:12 in reply to:  9 Changed 4 years ago by Gert Döring

Replying to novaflash:

I call it 2.5.0 because the filename and version number in the binary calls it that,

Not sure about the file name, but the version number in your logs says "2.5_git" - and the distinction is important. People search for bug reports, and then say "look, there was this bug in 2.5.0, I have seen it on trac!".

Bah, now you've made me curious why *some* builds of master show the commit ID, and others do not. Because, that's actually helpful in seeing what precise version is run...

(And yes, I'm very annoying to work with in regard to precise terminology :-) - I'm not paid for this, so I need to get my enjoyment in other ways!)

comment:13 Changed 4 years ago by Gert Döring

comment:14 Changed 4 years ago by novaflash

*throws music at you*

Note: See TracTickets for help on using tickets.