How can I find the source of connections coming from private IPs?

Question

I'm an amateur home network administrator and I'm trying to ensure that the network is as secure as I can make it. We have a cable connection going through a Linksys router (WRT320) with the dd-wrt firmware (v24-sp2 mini) blocking most incoming connections and forwarding a few. I'm no expert so I haven't been tweaking the settings too much. Everything is mostly at their default settings with nonessential services disabled.

I've been looking through the incoming connection logs and found that I'm receiving constant connection requests that are being dropped from the private IP, 10.160.0.1:bootpc (UDP) (port 68 I think). By the name, I initially thought it was some computer trying to remotely start up a computer in the network. After looking it up, it is my understanding that the service it is trying to connect to is the DHCP server on the router but I have no idea where those requests are coming from.

I'm doing this all from the webui for the router so the logs are pretty barebones. This is the kind of information I see:

Source IP    Protocol    Destination Port Number    Rule
10.160.0.1   UDP         bootpc                     Dropped
(repeated)

It is a Linux-based firmware so I should be able to poke my nose around. I just not that great with the administrative side of Linux.

All of the computers at home are accounted for. I know which computers are connected and they aren't running services that they shouldn't be. Wireless is secured so no unknown computers can connect AFAIK. I just don't know how to identify this rogue IP.

A potential source that this might be coming from is that some of our computers have remote login programs (LogMeIn) so my dad can connect to the computers remotely. However, the computers are off (or have it disabled) and he hasn't been using it as frequently as he used to. I would have thought that the IP address would have been showing as an actual non-private address if he was trying to connect anyway.

I also have a second wireless router that is acting as an access point and bridges connections to the main one. It's a Linksys WRT54GL with the same firmware with pretty much the same exact settings and everything -- the routers and all computers -- are on the same subnet AFAIK.

Where are these connections coming from?

---

Running tcpdump to check the packets, I see these entries:

root@WRT320N:/tmp# tcpdump -XX -e &> dump.txt
root@WRT320N:/tmp# cat dump.txt | grep 10.160.0.1
16:58:49.918259 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 300
16:59:07.303484 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 64: vlan 2, p 0, ethertype ARP, arp who-has 10.160.1.49 tell 10.160.0.1
16:59:32.351746 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 64: vlan 2, p 0, ethertype ARP, arp who-has 10.160.1.49 tell 10.160.0.1
16:59:37.574938 00:19:2f:e5:ba:d9 (oui Unknown) > 01:00:5e:00:00:01 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 2, p 0, ethertype IPv4, 10.160.0.1 > all-systems.mcast.net: igmp query v2
16:59:39.829927 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 341: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 295
16:59:40.767904 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 341: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 295
16:59:40.867497 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 64: vlan 2, p 0, ethertype ARP, arp who-has 10.160.1.49 tell 10.160.0.1
16:59:48.905628 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 341: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 295
16:59:49.132869 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 64: vlan 2, p 0, ethertype ARP, arp who-has 10.160.1.49 tell 10.160.0.1
16:59:51.378274 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 341: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 295
16:59:53.848036 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 300
17:00:10.841075 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 340: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 294
17:00:12.137809 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 340: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 294
17:00:14.179802 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 64: vlan 2, p 0, ethertype ARP, arp who-has 10.160.1.49 tell 10.160.0.1
17:00:16.196078 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 340: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 294
17:00:21.349701 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 300
17:00:22.445556 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 64: vlan 2, p 0, ethertype ARP, arp who-has 10.160.1.49 tell 10.160.0.1
17:00:23.366436 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 300
17:00:24.162903 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 340: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 294
17:01:04.274555 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 64: vlan 2, p 0, ethertype ARP, arp who-has 10.160.1.49 tell 10.160.0.1
17:01:07.439837 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 300
17:01:07.457221 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 300
17:01:09.454207 00:19:2f:e5:ba:d9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 2, p 0, ethertype IPv4, 10.160.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 300

^{trimmed for brevity}

I'm not sure what to make of it though. Searching online on all-systems.mcast.net shows a number of people also getting these packets too but with no real answers that I could see.

Solution 1

The DHCP traffic that you're seeing is special in that the source address is going to be 0.0.0.0 - not a lot of help there as far as finding the source.

This is unlikely to be anything to be alarmed about - this broadcast traffic should occur any time a device connects to the network, joins the wireless, etc.

If you do still want to hunt it down, you'll want to obtain the source MAC address of the traffic, and track it down from there.

Solution 2

BOOTP/DHCP traffic from the client during the DHCPDiscover phase (and during the DHCPRequest phase) is broadcast to every node on the same physical network (ff-ff-ff-ff-ff-ff/ 255.255.255.255) and it could be coming from any device; computer, game console, smart phone, etc., etc. In the DHCPDiscover and DHCPRequest packets you'll see the source MAC address of the client so you might be able to track it down by looking at that.

A client's DHCPDiscover and DHCPRequest packets originate from port 68 on the client destined for port 67 of a DHCP server.

A DHCP server's DHCPOffer and DHCPAck packets originate from port 67 on the server destined for port 68 of the client.

The traffic you're seeing could be originating from the client or the server, depending on which phase is occurring when you're seeing the traffic.

You can determine whether it's the server or the client by looking at the DHCP OpCode 53 value:

DHCPDiscover, DHCPRequest, and DHCPInform packets originate from the client.

DHCPOffer and DHCPAck packets originate from the server.

Comments

[dbasnett]

So you are saying that 10.160.0.0 is not one of your nets?

[Jeff Mercado]

AFAIK, no. I'm not really sure I know how to even set that up. One other detail I probably should mention is that there are two wireless routers in our network, the router mentioned in the question that accepts wireless N connections and another (WRT54GL same firmware) accepting wireless G connections. The second router is configured as access point and is bridging connections to the main router. The two routers (and all other computers) are on the same subnet.

[Chopper3]

Please read our FAQ before posting again, this isn't appropriate for this site, moving to SU

[Jeff Mercado]

@Chopper3: Sorry about that, it was pretty clear to me it was a networking problem so I naturally thought Server Fault was the place to go with this.

[JdeBP]

These are not "connection requests". UDP/IP is a connectionless protocol.

[Esteban]

See this please; this will give you your answer. It's a multicast IP, non-Internet address. IP multicast - Wikipedia, the free encyclopedia

[Shane Madden]

@JeffMercado Oh, it's probably a node that thinks it has that address, trying to renew a lease. If your log isn't capturing the MAC, you'll need a means of capturing the traffic - got something that can give you a mirror port?

[Jeff Mercado]

I'm not sure I do. Would I need special hardware for this or is it something the router should be able to do? I'm doing everything from the webui but it is essentially a linux-based firmware and could do sniffing there. Unfortunately my knowledge with that is somewhat limited.

[Shane Madden]

You'll want to look at tcpdump, then. Not sure how workable it is on a limited busybox install, but a quick search suggests that it's possible.

[Shane Madden]

Oh, good point - it might be a DHCP client process on the router talking to the ISP's DHCP server at that address.

[Jeff Mercado]

@JdeBP: So I guess these packets are harmless then.

[Jeff Mercado]

Well I used tcpdump and got the mac address. It's definitely not one of my machines. JdeBP's comment suggests this is coming from the ISP going out to someone. Probably harmless so I'll just ignore them.

[joeqwerty]

@JdeBP: Thanks. I should have paid closer attention to the info in the question. It's pretty clear to me now that this is server to client DHCP traffic.