Failed to renew dhcp ip address lease on tap windows adapter

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I have a Windows 10 laptop, which has developed an odd DHCP fault I’ve not seen before.

Until recently, the laptop connected wirelessly directly to the router provided by my ISP, and didn’t have issues. However, I recently moved it to a different Wireless Network inside my firewall, and joined it to my domain. All went well, except that ever since, the laptop really struggles to renew it’s IP lease from the DHCP server.

The default gateway on the workstations subnet (where the wireless network is) has a DHCP IP Helper configured (using RRAS), and forwards the request to my servers’ subnet which is 1 hop away. This works perfectly well for everything else on both subnets (servers all use DHCP and have static reservations configured on the DHCP server). There are other Windows 10 clients connected wired and wirelessly on the workstation subnet. I’ve tried various iterations of turning the wireless adapter off and back on, and ipconfig /release and ipconfig /renew without luck.

Initially, the laptop would lose connection every hour. The DHCP server was only giving out 1 hour leases as it had DHCP failover clustering configured on it, and the second node was down. I’ve resolved this now, and it’s giving out 8 hour leases again, but the laptop still gets the issue at the end of the 8 hours.

If the laptop is rebooted, it picks up an IP Address without any problems at all, but seems completely unable to renew an existing lease.

To confuse matters, it isn’t even able to pick up an IP Address if it’s connected back to the original wireless network on the ISP’s router. I’ve updated the wireless drivers on the laptop’s NIC (which were out of date), but this hasn’t made any difference.

OpenVPN Support Forum

Community Support Forum

Server 2012 TAP adapter problem acquiring IP

Server 2012 TAP adapter problem acquiring IP

Post by wahlfeld » Tue Dec 01, 2015 11:24 pm

I am having a problem with a VPN provider’s client software on my Windows Server 2012 R2 machine. I’m using TAP-Windows 9.21.1 and have two adapters in use: LAN adapter and the TAP adapter. I have NAT on the TAP adapter set to public and NAT on the LAN adapter set to private. I also have IPv4 routing and remote access server turned on. (let me know if you need any other details)

The issue seems to be that TAP adapter will incorrectly receive an IP address. The software will send the DHCP info to the TAP adapter:

Re: Server 2012 TAP adapter problem acquiring IP

Post by caribic » Thu Feb 15, 2018 7:58 am

I have a similar problem with server 2008. My TAP adapter receive no IP-Address and no routing information (i checked this with «ipconfig» and «route print» command) but in the openvpn log show this follow line:

Thu Feb 15 08:46:53 2018 open_tun
Thu Feb 15 08:46:53 2018 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\<1fefe625-84f5-4057-bff2-9c3b9810daa9>.tap
Thu Feb 15 08:46:53 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.144.0.22/255.255.255.252 on interface <1fefe625-84f5-4057-bff2-9c3b9810daa9>[DHCP-serv: 10.144.0.21, lease-time: 31536000]
Thu Feb 15 08:46:53 2018 Sleeping for 5 seconds.
Thu Feb 15 08:46:58 2018 Successful ARP Flush on interface [18] <1fefe625-84f5-4057-bff2-9c3b9810daa9>
Thu Feb 15 08:46:58 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Feb 15 08:49:03 2018 Warning: route gateway is not reachable on any active network adapters: 10.144.0.21
Thu Feb 15 08:49:03 2018 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem

If I disable and enable the TAP-Adapter in the adapter-settings during the vpn connect, than it works.

OpenVPN run with administrator rights and the firewall is disable. I have also test it with delay and sleep command. Nothing helps. Can anyone help me? Thanks a lot!

OpenVPN Support Forum

Community Support Forum

OpenVPN routing fails, but only sometimes. (windows client)

OpenVPN routing fails, but only sometimes. (windows client)

Post by bae3 » Sat Feb 05, 2011 4:11 am

I use Windows 7 and openvpn gui 2.1.4 client (with the «run as admin» checked) connecting to 2.1.4 server on linux.

I can’t get it to fail locally on my home network, but when on the road connected wirelessly at some hotel, the openvpn says it is connected but the default routing has failed and I can’t use the vpn properly, but openvpn will sit there as if it were properly connected. This is very frustrating as it isn’t consistently failing. Only sometimes.

When it fails, my client logs show a loop of these:

I have added «route-delay 0 60» to my client config, but that loop just gets longer (1 minute) but it still fails.

When it works, which is about 70% of the time it is usually successful (u/d=up) on the first attempt, but occasionally it might loop a few times before it is successful:

Sometimes when it fails I see this:
WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: The system cannot find the file specified. (code=2)
or:
WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: The name specified in the network control block (NCB) is in use on a remote adapter. The NCB is the data. (code=5322)
or:
TAP: DHCP address renewal succeeded

But sometimes when it succeeds I see this:
WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: The system cannot find the file specified. (code=2)

So I don’t know if it is related.

Is there any way to make it reliable without changing to some other non-dhcp/default route setup? I like it the way it is when it works, I just want it to reliably set the route. (setting a longer timeout on the attempts doesn’t seem like a way to gain reliability, it might just loop for 5 minutes and fail. )

Re: OpenVPN routing fails, but only sometimes. (windows clie

Post by hostizzle » Fri Feb 11, 2011 4:37 am

To me, this is the biggest issue reducing the uptake and installation of OpenVPN worldwide. I have far, far more downloads than I do installations on my server, and I think the routing issue is why.

Why is it that the Windows native PPTP client routes faultlessly in any configuration, yet the OpenVPN client has to be explicitly told how to route and many times still fails at this task?

Plenty of users have told me they run the client explicitly as admin under Windows 7, yet still fail at setting up routing.

I don’t mean to offend anyone here who has worked on this excellent project—it truly must be a labor of love.

Routing is a huge mystery to even me, an OpenVPN server admin. Surely it must be just as mysterious to end users all over the world.

Re: OpenVPN routing fails, but only sometimes. (windows clie

Post by bae3 » Sun Feb 20, 2011 3:57 am

There is no solution? I can not find anything in the configuration that is wrong.

It just doesn’t work «sometimes» which is very frustrating.

Re: OpenVPN routing fails, but only sometimes. (windows clie

Post by janjust » Mon Feb 21, 2011 7:37 am

to your client config file.

As for OpenVPN not being to route properly vs the Windows native PPTP client: in a lot of cases the client is running some kind of antivirus software which is tested against the native PPTP client but which has not been tested against OpenVPN’s TAP-Win32 adapter. This often causes problems. The routing capabilities of OpenVPN far exceed those of the native PPTP or L2TP clients but as always, with great power/flexibility comes great responsibility.

Re: OpenVPN routing fails, but only sometimes. (windows clie

Post by bae3 » Mon Mar 07, 2011 3:40 am

That didn’t help — it still fails, sometimes.

I tried setting the TAP device to «Always active», but that didn’t help either.

It seems to fail more frequently after a hibernation . but I can’t force it to fail on demand.

I can’t find a way to have it auto disconnect/reconnect if the TAP-Win32 adapter has an IP of 169.254.. or 0.0.0.0 either.

Re: OpenVPN routing fails, but only sometimes. (windows clie

Post by billb3 » Thu Apr 28, 2011 3:11 pm

Been having the same issue for months. Very frustrating, since it is the thing holding up our Windows 7 roll-out. Have you had any luck fixing this?

Here is a bug I opened:

It was also discussed on the mailing list. A few responses from Samuli:

Re: OpenVPN routing fails, but only sometimes. (windows clie

Post by Daniel S » Sun Jan 01, 2012 1:46 pm

Re: OpenVPN routing fails, but only sometimes. (windows clie

Post by JStone » Thu Jan 05, 2012 4:55 am

Re: OpenVPN routing fails, but only sometimes. (windows clie

Post by Mimiko » Sat Jan 07, 2012 9:43 am

On windows systems espacially on server ones, the APIPA technology causes problem to bringin up the TUN interface. The issue varies from system to system and depends on the drivers of the networks that joins the system core with network drivers. So there is two possibilities to resolve:
1) Disable APIPA and set the IP to tun interface as static (there is a bug in windows which disables dhcp retriving of IP when APIPA is disabled).
2) Use route-delay 60 60 (the first parameter delays IP set to the tun interface, not the second, and it must be the minimum amount of time for the system to bring up interface and set IP using APIPA, otherwise it will fail).

From my experience, slower hardware will need more time to bring up TUN interface. While Windows 2008 server seems have resolved the issue, so a default route-delay of 10 seconds is enough.

OpenVPN disconnection issue

I have a user that is having issues with a VPN connection back to the office where it will disconnect on a regular basis and reconnect. This happens will all VPN clients as he connects to multiple customer networks. He is on OpenVPN (not sure what the VPN server is on the office end) Windows 8.1 64-bit on an Acer Aspire M5. He also has issues transferring files while on his LAN in the office, the transfer will start, fail, retry and eventually finish.

Looking at the logs for the OpenVPN connection logs I am seeing these lines that are displaying the disconnect

Sun Jun 08 12:14:11 2014 Start net commands.

Sun Jun 08 12:14:11 2014 C:\WINDOWS\system32\net.exe stop dnscache

Sun Jun 08 12:14:16 2014 C:\WINDOWS\system32\net.exe start dnscache

Sun Jun 08 12:14:16 2014 ERROR: Windows ipconfig command failed: returned error code 2

Sun Jun 08 12:14:16 2014 C:\WINDOWS\system32\ipconfig.exe /flushdns

Sun Jun 08 12:14:16 2014 C:\WINDOWS\system32\ipconfig.exe /registerdns

I was thinking a permissions issue, but he is a local admin and has used secondary authentication with the same result.

For the LAN issue of transferring files, I may have him run Wireshark and send me the logs. All of his issues seem to stem from a network driver, but it happens wired or wirelessly.

Устранение неполадок на клиенте DHCP Troubleshoot problems on the DHCP client

В этой статье описывается, как устранять неполадки, возникающие на DHCP-клиентах. This article discusses how to troubleshoot problems that occur on DHCP clients.

Контрольный список по устранению неполадок Troubleshooting checklist

Проверьте следующие устройства и параметры: Check the following devices and settings:

Кабели подключены и работают. Cables are connected and working.

Фильтрация MAC включена для коммутаторов, к которым подключен клиент. MAC filtering is enabled on the switches to which the client is connected.

Сетевой адаптер включен. The network adapter is enabled.

Установлен и обновлен правильный драйвер сетевого адаптера. The correct network adapter driver is installed and updated.

Служба DHCP-клиента запущена и запущена. The DHCP Client service is started and running. Чтобы проверить это, выполните команду net start и найдите DHCP-клиент. To check this, run the net start command, and look for DHCP Client.

На клиентском компьютере нет портов блокировки брандмауэра 67 и 68. There is no firewall blocking ports 67 and 68 UDP on the client computer.

Журналы событий Event logs

Изучите журналы событий администратора Microsoft-Windows-DHCP Client Events/Operation и Microsoft-Windows-DHCP Client Events. Examine the Microsoft-Windows-DHCP Client Events/Operational and Microsoft-Windows-DHCP Client Events/Admin event logs. Все события, связанные со службой клиента DHCP, отправляются в эти журналы событий. All events that are related to the DHCP client service are sent to these event logs. События клиента Microsoft-Windows-DHCP находятся в Просмотр событий в разделе журналы приложений и служб. The Microsoft-Windows-DHCP Client Events are located in the Event Viewer under Applications and Services Logs.

Команда PowerShell Get-NetAdapter-Инклудехидден предоставляет необходимые сведения для интерпретации событий, перечисленных в журналах. The «Get-NetAdapter -IncludeHidden» PowerShell command provides the necessary information to interpret the events that are listed in the logs. Например, идентификатор интерфейса, MAC-адрес и т. д. For example, Interface ID, MAC address, and so on.

Сбор данных Data collection

При возникновении проблемы рекомендуется одновременно выполнять одновременное получение данных как на клиенте DHCP, так и на стороне сервера. We recommend that you collect data simultaneously on both the DHCP client and server side when the problem occurs. Однако в зависимости от фактической проблемы можно начать исследование, используя один набор данных на DHCP-клиенте или DHCP-сервере. However, depending on the actual problem, you can also start your investigation by using a single data set on either the DHCP client or DHCP server.

Чтобы получить данные с сервера и затронутого клиента, используйте Wireshark. To collect data from the server and affected client, use Wireshark. Начните сбор в то же время на DHCP-клиенте и на компьютерах DHCP-сервера. Start collecting at the same time on the DHCP client and the DHCP server computers.

На клиенте, на котором возникла проблема, выполните следующие команды: Run the following commands on the client that is experiencing the problem:

Затем Wireshark на клиенте и сервере. Then, stop Wireshark on the client and server. Проверьте созданные трассировки. Check the generated traces. Они должны, по крайней мере, сообщать о том, на каком этапе прекращается обмен данными. These should, at least, tell you at which stage the communication stops.