Can someone educate me about these logged accepted packets?

[Deleted member 27741]

kernel: ACCEPT <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:MAC:not:from:any:device:in:my:network <1>SRC=NOT.FROM.MY.SUBNET DST=255.255.255.255 <1>LEN=344 TOS=0x00 PREC=0x00 TTL=255 ID=17650 PROTO=UDP <1>SPT=67 DPT=68 LEN=324

Hi all, above is an accepted packet from my log when the firewall is set to log accepted packets (I believe it is a dhcp packet). One thing I do not understand is that the SRC address is not from an ip address on my network. Nor is it even on the same subnet my network is on. Why is that? The ip address is not from my modem either.

 

[mstombs]

A dhcp reply from your ISP dhcp server?
There's a specific iptables ACCEPT rule for these in your INPUT chain, something todo with the broadcast/unicast mix of udp messages used in the dhcp protocol and the fact that ISPs tend to have clusters of dhcp machines behind a dhcp-relay means the messages are missed by ESTABLISHED/RELATED accept rule.

admin@RT-N66U:/tmp/home/root# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 418K   34M ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
  690 28833 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
 177K   28M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
  563 93462 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           state NEW
59116   10M ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
  939  314K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68
    3   180 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8082
 7390  629K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

 

[Deleted member 27741]

Hmm... I think you may be on the right track with something from my ISP. Does NAT modify the source of packets? I also think it may have something to do with NAT modifying the source but can't find much information on that.

 

[Deleted member 27741]

I must add that the source is from a local address! It comes from the 10.*.*.* set, but is not the same as my router's subnet (which is also somewhere in the 10.*.*.* range).

 

[mstombs]

In your original message the packet comes from eth0 which is the WAN on asuswrt. Why wouldn't your ISP use non-internet routable IP address for routers and dhcp servers within their network? I hope you are only using a small subset of the 10.* range or that will confuse the router!

 

[Deleted member 27741]

I am using 255.255.255.0 so yes, a small subset of 10. Perhaps using 10 is a mistake in itself, I have seen no concrete evidence of this, however.

That is correct, the packet comes from eth0 (WAN). Why wouldn't they use a non-internet routable IP address? Well that is only a piece of the puzzle here. Does your ISP use a local address (not on your subnet) for dhcp (but comes from WAN)? Does the MAC address (aside from the broadcast frame part) not match anything on your network, including the CMTS mac of your modem? The modem addresses, including the CMTS address seem to be a set of six numbers, not eight.

 

[ColinTaylor]

mstombs is correct. This is just DHCP broadcasts from the CMTS network. There is no problem with your subnet being on 10.x.x.x because it is NATed (to your WAN address). This is a totally normal setup, nothing unusual.

MAC addresses are 6 octets.

 

[Deleted member 27741]

Yeah, I didn't really think it was unusual, just confusing for those that don't know where all this stuff comes from, e.g.- why is the src not on my subnet? I guess that it is the address of THEIR subnet for the CMTS network.

 

[ColinTaylor]

why is the src not on my subnet? I guess that it is the address of THEIR subnet for the CMTS network.

Exactly. It's traffic from other customers connected to the same CMTS as you.

 

[Deleted member 27741]

Soooo, some device probably owned by another customer of my isp is sending out dhcp packets on the same CMTS that I am on, and for this reason I am seeing them come from WAN on a local ip range? My cable comes from a cox box that goes to my and my neighbor's house, could this be dhcp packets sent from their modem to the same CMTS then? If this means my neighbor uses a non 192.168.*.* ip range, I have a newfound respect for my neighbor's home routing skills.

 

[ColinTaylor]

It could be stuff from lots of different customers in your area (possibly hundreds). The traffic is not really entering your network. The packets are being broadcast to all the devices (cable modems) on the ISP's local network (not your LAN). i.e cable modems being powered on or having their leases renewed.

Admittedly it's a bit confusing in that quite often the cable modem will stop that traffic from reaching your router so you wouldn't see it at all. That said, here in the UK that was the standard setup for years.

 

[Deleted member 27741]

Then it is traffic intended for modems (mine and others) and it is not necessary for it to reach my router? I suppose I could block it for a couple days and see what happens.

 

[Deleted member 27741]

Upon further inspection of my logs (and blocking some things in iptables) I think these packets may not be innocuous after all. I got these in my dropped packet list, looks like the same mac (zeroed part is the same in both packets) sending DHCP broadcasts is also poking at RDP. If that port were forwarded on my network I suppose they would try to log in. Nslookup on SRC of second packet is victorias2.idfnv.net.

DROP <4>DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00 <1>SRC=not.on.my.subnet DST=255.255.255.255 <1>LEN=344 TOS=0x00 PREC=0x00 TTL=255 ID=49578 PROTO=UDP <1>SPT=67 DPT=68 LEN=324

DROP <4>DROP IN=eth0 OUT= MAC=my:router:mac:add:re:ss:00:00:00:00:00:00:00:00 <1>SRC=93.174.93.164 DST=my.wan.addr.ess <1>LEN=48 TOS=0x00 PREC=0x00 TTL=122 ID=48127 PROTO=TCP <1>SPT=41097 DPT=3389 SEQ=1450619807 ACK=202352976 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402)


Or, maybe I just don't know that the latter part of the MAC means?

 

[ColinTaylor]

They're different things. The first is the broadcast we previously discussed. The second is the usual hacking/probing attempts we all get from the internet. 93.174.93.164 is somebody in the Netherlands.

One MAC address will be your WAN interface and the other will be the MAC of the last network device the data passed through, probably a router or cable modem. That way the network knows where it's going and where it came from.

 

[Deleted member 27741]

Ah, sweet! So the MAC has two extra number sets at the end if there are two six set MAC addresses what are those last two sets of numbers for?

That second MAC, it should not be the MAC of my cable modem, right? I have cable internet with a modem/router in bridged mode.

 

[ColinTaylor]

Ah, sweet! So the MAC has two extra number sets at the end if there are two six set MAC addresses what are those last two sets of numbers for?

I believe it is the EtherType field. It probably contains 0x0800 which is the flag for IPv4.
https://en.wikipedia.org/wiki/Ethernet_frame#Ethernet_II
https://en.wikipedia.org/wiki/EtherType

That second MAC, it should not be the MAC of my cable modem, right? I have cable internet with a modem/router in bridged mode.

Probably. Type the value in here: http://www.macvendorlookup.com/
It'll probably be some Cisco kit on your ISP's premises or the manufacturer of your cable modem. (I'm not to sure of the effects of DOCSIS/bridge mode on Ethernet packets )

 

[mstombs]

It could be stuff from lots of different customers in your area (possibly hundreds). The traffic is not really entering your network. The packets are being broadcast to all the devices (cable modems) on the ISP's local network (not your LAN). i.e cable modems being powered on or having their leases renewed.

Admittedly it's a bit confusing in that quite often the cable modem will stop that traffic from reaching your router so you wouldn't see it at all. That said, here in the UK that was the standard setup for years.

When I first got a cable modem (Terayon TJ210) some 15 years ago there was a lot of chatter from other users making big dent in the 64kB service, and the arp traffic tended to give routers 'neighborhood table overflows'. This was fixed with an ISP upgrade, essential since they increased the size of the dhcp pool.