Opened 4 years ago

Closed 20 months 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)

openvpn-broken-tuntap1.txt (23.8 KB) - added by Gorkhaan 4 years ago.
openvpn-working-tuntap1.txt (5.1 KB) - added by Gorkhaan 4 years ago.
client.ovpn (290 bytes) - added by Gorkhaan 4 years ago.
server.txt (636 bytes) - added by Gorkhaan 4 years ago.

Download all attachments as: .zip

Change History (10)

Changed 4 years ago by Gorkhaan

Attachment: openvpn-broken-tuntap1.txt added

Changed 4 years ago by Gorkhaan

Attachment: openvpn-working-tuntap1.txt added

Changed 4 years ago by Gorkhaan

Attachment: client.ovpn added

Changed 4 years ago by Gorkhaan

Attachment: server.txt added

comment:1 Changed 4 years ago by plaisthos

Is DHCP Server running on the same *physical* machine as the VPN Server? I have seen weird checksum problems in such scenarios.

comment:2 Changed 4 years ago by Gorkhaan

I tried to use isc-dhcp-server on the same VM where openvpn server is running. It did not help. isc-dhcp-server what I want to use is not running on the same physical machine

(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. :-)

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

comment:3 Changed 4 years ago by Samuli Seppänen

Component: tap-windowstap-windows6
Owner: set to jamesyonan
Status: newassigned

comment:4 Changed 3 years ago by Samuli Seppänen

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 3 years ago by Gorkhaan

Hi

Sorry for the late reply. It works with the latest versions of OpenVPN.
This ticket can be closed. Thanks.

comment:6 Changed 20 months ago by Gert Döring

Resolution: fixed
Status: assignedclosed

Thanks for the feedback. Somehow this got overlooked in the flurry of other activities...

Glad to hear that it works now.

Closing the ticket! :-)

Note: See TracTickets for help on using tickets.