DHCP nak on WAN

Unanswered Question
Jul 11th, 2007

Recently, my ISP disabled my internet connection. I was told because my router was sending out ?funny? traffic on their network. They could not tell me exactly what the traffic is, but they said it was my IP address broadcasting itself on their network.

Since they didn?t know what it was, I proceeded to sniff my WAN connection. I saw what I believe to be the traffic they are talking about. From what Wireshark says, it is a DHCP nak and it broadcasts itself every minute or so. I have posted a screenshot at www.pcexhaust.com/cisco.jpg

My setup is this:

Cisco 1710 (12.4 IOS) connected to my ISP. My ISP provides me with an Ethernet connection to their servers. They are running DHCP. My Cisco WAN is set to receive a DHCP address (ip address DHCP) and it does receive an address. I have turned the keep alives off (no keepalive) on my WAN interface. But, when I asked the ISP, this was not the traffic they were seeing. Besides setting the WAN to receive DHCP address and half-duplex, that is ALL that is configured on the router.


Is this DHCP nak traffic normal, or is there something wrong with either my side, or my ISP's side?

Thank you

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (3 ratings)
Edison Ortiz Wed, 07/11/2007 - 08:09

Since the ISP disabled your internet connection, the DHCP NAK you are seeing may be normal. It depends how they disabled your internet connection.

I guess the traffic they were implying may be illegal download (peer-to-peer application) or terms-of-service's abuse

pcexhaust Wed, 07/11/2007 - 08:37

From what I can tell, they didn't disable the port itself but would no longer allow me to pull an IP address from the port... even if I changed my MAC address.

When I called tech support, I talked to a tech that allowed me to plug my router back in and he could watch my traffic. The tech saw the funny traffic but did no know what it was. He just said it was broadcasting my IP address on their network and that is why they shut it down. I did a further investigation to figure out the broadcast is DHCP nak related.

It is not at all related to P2P. The port was deactivated while all the computers on my network were turned off. And, I know for sure I haven't ran any P2P applications in the last two weeks and even then, it wasn't illegal... just Fedora 7.

Any other ideas to if this DHCP nak is normal, or if something is wrong?

PS. I know the MAC address says NETGEAR in WireShark. This is correct because I cloned the MAC of a NetGear router on my Cisco WAN side.

nikolay-shopik Wed, 07/11/2007 - 08:45

They better to tell you what kind of funny traffic they see. It's just silly if provider shutdown your port because of unknown funny traffic ;)

At least if you are sure you have simple setup they should tell you what kind of broadcasting they seen.

pcexhaust Wed, 07/11/2007 - 08:54

I agree that they should tell me exactly what they see. But, the guy I talked with (who seems pretty high up in the help desk tiers)only could tell me it was broadcast traffic from my IP to I think it is DHCP related because it's the only thing that I could find.

I'll talk to them again tonight and see if I can get more out of them.

pcexhaust Thu, 07/12/2007 - 04:02


I was able to get more information from tech support. They are telling me I am broadcasting on port 67. From what I can tell, this is port is used for DHCP servers (BOOT PS). Is this correct? I have the DHCP service turned off on my router, so I'm not sure why I would be broadcasting on this port.

Anyhow, I created an ACL that blocks outbound port 67 which I'm using as a temporary fix.

Edison Ortiz Thu, 07/12/2007 - 06:30

Well, you are supposed to broadcast DHCP request since you don't have a static IP on the router's connection to the ISP. I'm not sure what the problem really is, here.

If the router is constantly broadcasting this kind of packet, perhaps there is a problem with the connectivity and the interface is getting reset. It's similar to constantly rebooting a workstation on a LAN, check the local DHCP server and you will see the same behavior.

Richard Burts Thu, 07/12/2007 - 07:03


I am curious about the DHCP nak. A nak is usually a response to something that you received. In your packet capture do you see the provider sending anything to you (especially on ports 67 or 68)?

Another point to consider, I do not believe that your access list is going to be effective. If the DHCP nak is being generated by your router then the access list will not prevent it being tranmitted. One of the behaviors of outbound access lists on routers is that they do not filter traffic that is generated by the router itself.



pcexhaust Thu, 07/12/2007 - 07:15


No, I do not see anything from my provider. All I have is just what is in that screenshot at http://www.pcexhaust.com/cisco.jpg

My sniffing doesn't seem to be picking up everything like it was a few nights ago. In my current setup, I am using a hub between my WAN and my ISP's ethernet port. To this hub, I am connecting my laptop and running Wireshark in promiscuous mode. The hub is so I can sniff everything that goes through the network. That being the Cisco's WAN traffic.

Is there a better way I can be looking for traffic?

P.S. Thank you for informing me about the ACL behavior.

pcexhaust Thu, 07/12/2007 - 07:05

EdisonOrtiz, I agree. I do know what the problem is here. However, they say it is a problem. Wiki tells me that "all client-sent packets have source port 68 and destination port 67." This may mean my DHCP request will no longer work. However, I did test it been I installed the ACL, and it got an IP.

I'm not sure what my ISP's problem is. Whatever software they are using keeps flagging my Cisco router as a rouge on their network.

Richard Burts Thu, 07/12/2007 - 07:27


Is it possible that there is something else connected on the hub that might be sending packets (especially packets with a source address that does not match the subnet of the router interface)? When I look up the DHCP nak, I find that it usually is sent from a server when a client has an incorrect notion of the network address.



pcexhaust Thu, 07/12/2007 - 07:39


The only thing connected to the hub on my side is my laptop and the router. Now, when I sniff, I see a lot more stuff then I should (IPv6, AIM, HTML,UPnP) from other IPs. It appears (maybe?) that my ethernet drop runs to a hub and not a switch. This may explain why I'm having to run at half-duplex in that the hub may be a very old device.

From the traffic I see, it's all from either a 10.1.x.x or 208.45.x.x network. The 10 network belongs to my ISP as well. The 10 network hosts a portal page that everyone gets redirected in the morning so they can log into the network.

Can you explain more about the nak? My feeling is this nak is just checking to make sure no one else has the same IP that I was assigned. As in, if someone receives my nak and has the same IP as me, then it (the other router) will request a new IP from the DHCP server.

Richard Burts Thu, 07/12/2007 - 08:16


It is not a probe to find whether someone is using your address. Here is a section from RFC 2131 which describes the DHCP nak: If the client's request is invalid (e.g., the client has moved to a new subnet), servers SHOULD respond with a DHCPNAK message to the client.

The packet capture that you posted clearly shows that there was a DHCPDISCOVER and a DHCPREQUEST transmitted from some end station (numbers 73 and 75). It would be very interesting to see the details of the DHCPREQUEST, especially whether the end station is suggesting an IP address (which is a normal behavior) which is not on the local subnet.

In the meantime there might be a way to protect yourself against this problem while it is being worked out. I mentioned previously that an outbound access list will not filter any traffic that is generated by the router. But an inbound access list will filter all traffic. If you configure an inbound access list that denies traffic to UDP destination port 67 then your router will not see this DHCP traffic and I think that your broadcasting of DHCP nak will stop. Note that you still need to be able to receive UDP destination port 68 so that you can lean your address from the provider.




This Discussion