USG110 - DHCP Discover failed on WAN1 Port

USG_User

Presently we're experiencing failed DHCP lease renewals with our ISP1 on WAN1. We have the following general configuration:

WAN1:  connected to a Cisco Switch (owned by ISP1) where the fiber line (100/100 Mbit) is connected to. IP address will be obtained by DHCP.

WAN2: connected to a router (owned by ISP2) where DSL (50/10 Mbit) is connected to. Fixed IP is set at USG and assigned fixed IP from ISP2 is set at Fritzbox.

WAN2 should work as failover line only, means without configuring any BWM.

Further we have a WAN trunk failover procedure in place:

And finally the failover will be triggered by a regular connectivity check on WAN1 as follows:

In general it works fine, but during the last days our WAN1 connection gets regularly lost. It has been turned out, that we could make a manual RENEW to get back our IP address and the connection. That's why we know that there is something wrong with the DHCP conversation.

Our ISP says, the problem is on our side. In general, and allthough we got a fix IP address, this IP has to be renewed regularly by DHCP about every 2h. Configuring the fix IP in our USG doesn't work. Not nice, but OK. It's a requirement of the ISP.

But often the ISP DHCP Server returns a DHCP_NAK to our DHCP_REQUEST. And on a NAK packet the USG should normally start a complete new DHCP_DISCOVER. But it doesn't. And in that case we lost our connection. This has been checked by WireShark from ISP side.

Unfortunately this cannot be intentionally reproduced. Mostly the DHCP server is returning a DHCP_ACK to our DHCP_REQUEST to renew the lease. But even sometimes also a DHCP_NAK without further reaction from USG.

Has anybody experienced similar problems with DHCP?

We also thought about our WAN1 connectivity check. Could it interfere the DHCP renewal process when a simultaneously made connectivity check failed while the DHCP server is responding a NAK and thatswhy WAN1 is loosing its IP for a short time? In that case the USG failover procedure might switching-over to WAN2 and the IP renewal on WAN1 could not be finished. I know it's far-fetched.

Any ideas?

USG_User

Finally Zyxel provided us with a WK32 firmware which fix the issue. Now USG110 is correctly answering with a new DHCP DISCOVER after receiving a DHCP NAK from ISP's DHCP server. Thanks to Zyxel_Stan for excellent cooperation.

Hope that the fix will be permanently integrated into next official firmware release.

USG_User

Will DHCP events be logged in USG log? For us it seems that only internal DHCP event (from LAN1, LAN2, etc) being logged but not WAN events. Could anybody confirm this?

Zyxel_Stanley

Hi @USG_User

As you mentioned you have captured DHCP packets on WAN1.
Can you share the DHCP packet for further check the reason?

USG_User

Hi Stan,

until yesterday only our ISP has captured packets and provided us with screenshots. Since today, where we've mirrored the port, we are capturing packets by ourselves, too. Now we are wating for further DHCP requests from USG and new failure events.

Nevertheless could you confirm that DHCP events on WAN ports won't be logged in USG?

PeterUK

Does your WAN IP change a lot?

To me it seems your ISP DHCP server is not working correctly.

One thing you could try is put a ACL switch between the Cisco Switch and USG110 VLAN two ports untagged on the USG side (not on the USG).

Permit

destination 255.255.255.255

Address Prefix 32

source port 68

destination port 67

deny

destination any

source port 68

destination port 67

This will make block the USG request by Unicast and will do a broadcast request at the end of the lease.

You could also ask for the DHCP ACK/offer for Unicast with this in console

configure terminal

interface wan1

ip address dhcp unicast

write

Zyxel_Stanley

Hi @USG_User

You can filter 67 service port when capturing packets prevent too much packets are not required.

In current design, there is no DHCP log during WAN interface renew address. But you still can use CLI command to show interface status when issue happening.

USG_User

Thanks guys,

@Peter: No, our IP is fix and will never be changed. Nevertheless the ISP requires an assigning by DHCP. We've already tried to set our fix IP into the USG config - but it doesn't work.

As said, in the meantime we have a managed switch arranged in between of the USG and the Cisco Switch. The entire traffic is being copied to another port where WireShark is listening and is filtering for DHCP packets. In the meantime it looks good so far. Regularly, every 3600 s, the USG is sending a DHCP_REQUEST to renew its IP, followed by a DHCP_ACK from DHCP Server at ISP side. All seems as it should be. Will see ...  I keep you informed. As soon as we see a DHCP_NAK packet, we will forward it to Stan for analysis.

PeterUK

Also check that ARP for the gateway is replying.

USG_User

Hi Stan and Peter,

A few minutes ago we've lost our IP again. But fortunately WireShark has captured our last USG DHCP_REQUEST packet as well as the DHCP Server DHCP_NAK response which caused the lost of the IP.

First we will ask our ISP why its DHCP server suddenly replied an NAK while the whole days it was sending ACKs.

But on the other hand, why the USG is still sending DHCP_REQUESTs after receiving a NAK? We captured different REQUESTS during a few minutes. Normallyby standard procedure it should completely restart the process with a DHCP_DISCOVER packet. Firstly when I manually trigger the renewal within GUI of the USG, a DISCOVER packet will be sent and the server makes an offer.

Below please find the last USG REQUEST followed by DHCP Server's NAK packet. The REQUEST packet seems not differing from other REQUEST packets used successfully the whole day.

Last USG110 DHCP REQUEST packet:

DHCP Server's NAK packet:

As said above, allthough receiving a NAK packet, USG was still sending only REQUESTs instead of DISCOVER packets, as you can see as follows:

Do you see anything suspicious?

PeterUK

So the bit you blanked out for the bottom DHCP looks like its doing Unicast requests after discover with the DHCP server and getting a ACK but then for no reason you get a NAK and DHCP requests by broadcast the DHCP server is not interested until you do a discover. 

what is a bit odd but might be to do with the NAK is the requests after that are not from your source IP but from 0.0.0.0  

To me your ISP DHCP server is in the wrong here.

So try the following in the console 

configure terminal

interface wan1

ip address dhcp unicast

I guess zyxel could implement fix so that when it sees a NAK it does a discover but will that work without a packet loss at that time when your ISP sends a NAK to the USG doing discover? 

Zyxel_Stanley

Hi @USG_User
DHCP Client will send DHCP_Request before IP lease timeout. Even DHCP server reply NAK, DHCP client will use the exist IP address until it is timeout. 
When IP lease is timeout, DHCP client will request(DHCP_Discover) new IP address again.
If you like, you can send all of captured packets to me by private message.