Opened 10 years ago
Closed 7 years ago
#456 closed Bug / Defect (fixed)
TUN/TAP V9.21 does not get dhcp settings whereas V9.9 works
Reported by: | Gorkhaan | Owned by: | jamesyonan |
---|---|---|---|
Priority: | major | Milestone: | release 2.5 |
Component: | tap-windows6 | Version: | OpenVPN 2.3.4 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: |
Description
Network setup:
- KVM Bridged OpenVPN Server
- tap0 and eth1 running promisc mode bridged to br250 on KVM VM
- server-bridge mode
- ip helper-address works
- Server: Debian 7, OpenVPN 2.2.1 x86_64-linux-gnu
- isc-dhcp-server running, giving out IPs for 10.0.250.0/24
Problem:
- V9.21.0 TUN/TAP on Windows 8.1 x64 does not acquire IP from isc-dhcp-server. I hangs if I try to close the interface pressing F4 in CMD window. Only reboot helps
- V9.9 TUN/TAP on Windows 8.1 x64 works like charm.
Relevant Log:
WORKING
SYSTEM ADAPTER LIST
TAP-Windows Adapter V9
Index = 15
GUID = {FFFC52E9-5960-46D9-933F-4AF8360CB0FF}
IP = 10.0.250.21/255.255.255.0
MAC = 00:ff:ff:fc:52:e9
GATEWAY = 0.0.0.0/255.255.255.255
DHCP SERV = 10.0.106.1/255.255.255.255
DHCP LEASE OBTAINED = Tue Oct 07 13:35:23 2014
DHCP LEASE EXPIRES = Tue Oct 07 14:35:23 2014
DNS SERV = 10.0.106.2/255.255.255.255 8.8.8.8/255.255.255.255 8.8.4.4/255.255.255.255
BROKEN
SYSTEM ADAPTER LIST
TAP-Windows Adapter V9
Index = 18
GUID = {41C85F7F-C3F1-4C09-B4AB-CE1E2FB77634}
IP = 169.254.54.166/255.255.0.0
MAC = 00:ff:41:c8:5f:7f
GATEWAY = 0.0.0.0/255.255.255.255
DHCP SERV = 0.0.0.0/255.255.255.255
DHCP LEASE OBTAINED = Tue Oct 07 13:27:53 2014
DHCP LEASE EXPIRES = Tue Oct 07 13:27:53 2014
DNS SERV =
DHCP Logs
Oct 7 11:27:39 poc-powavpn-1 dhcpd: DHCPOFFER on 10.0.250.10 to 00:ff:c8:f1:74:0e (GBLONHTL010066) via br250
Oct 7 11:27:39 poc-powavpn-1 dhcpd: DHCPDISCOVER from 00:ff:c8:f1:74:0e (GBLONHTL010066) via br250
Oct 7 11:27:39 poc-powavpn-1 dhcpd: DHCPOFFER on 10.0.250.10 to 00:ff:c8:f1:74:0e (GBLONHTL010066) via br250
Oct 7 11:27:44 poc-powavpn-1 dhcpd: DHCPDISCOVER from 00:ff:c8:f1:74:0e (GBLONHTL010066) via br250
Oct 7 11:27:44 poc-powavpn-1 dhcpd: DHCPOFFER on 10.0.250.10 to 00:ff:c8:f1:74:0e (GBLONHTL010066) via br250
Oct 7 11:27:49 poc-powavpn-1 dhcpd: DHCPDISCOVER from 00:ff:c8:f1:74:0e (GBLONHTL010066) via br250
Oct 7 11:27:49 poc-powavpn-1 dhcpd: DHCPOFFER on 10.0.250.10 to 00:ff:c8:f1:74:0e (GBLONHTL010066) via br250
Oct 7 11:27:56 poc-powavpn-1 dhcpd: DHCPDISCOVER from 00:ff:c8:f1:74:0e (GBLONHTL010066) via br250
<<< This goes on ... >>>
So DHCPACK never happens.
Attachments (4)
Change History (10)
Changed 10 years ago by
Attachment: | openvpn-broken-tuntap1.txt added |
---|
Changed 10 years ago by
Attachment: | openvpn-working-tuntap1.txt added |
---|
Changed 10 years ago by
Attachment: | client.ovpn added |
---|
Changed 10 years ago by
Attachment: | server.txt added |
---|
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
I tried to use isc-dhcp-server on the same VM where openvpn server is running. It did not help.
(Moreover for my multimaster solution running dhcp on the openvpn server won't be feasable.)
It may have something to do with the TUN/TAP driver. Because I tried Viscosity as well. It worked even on Mac OS X with Tunnelblick. :-)
comment:3 Changed 9 years ago by
Component: | tap-windows → tap-windows6 |
---|---|
Owner: | set to jamesyonan |
Status: | new → assigned |
comment:4 Changed 9 years ago by
Milestone: | → release 2.5 |
---|
Can you try reproducing this with OpenVPN 2.3.6 (or later) on both server- and client-side? There were several tap-windows6 -related fixes in 2.3.5 which may have solved this issue. We don't support 2.2.1 anymore, either, so if the problems lies there it won't get fixed.
comment:5 Changed 9 years ago by
Hi
Sorry for the late reply. It works with the latest versions of OpenVPN.
This ticket can be closed. Thanks.
comment:6 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Thanks for the feedback. Somehow this got overlooked in the flurry of other activities...
Glad to hear that it works now.
Closing the ticket! :-)
Is DHCP Server running on the same *physical* machine as the VPN Server? I have seen weird checksum problems in such scenarios.