OT: What Are All These Probes From My Firewall Log????

Home » CentOS » OT: What Are All These Probes From My Firewall Log????
CentOS 13 Comments

I’m getting a gazillion of these probes in my firewall logs. I don’t understand what’s going on here,… These all look like bootp requests from, to

there’s certainly no 10.x.x.x here on this network, and I don’t get the destination address… is it possible to send packets out onto the internet addressed like that?

whois doesn’t turn up anything on

Anybody got suggestions on how I’d track this down?


Aug 16 21:13:59 kernel: DROP <4>DROPIN=eth0 OUT= MAC

13 thoughts on - OT: What Are All These Probes From My Firewall Log????

  • that looks like DHCP requests. maybe there’s some piece of network gear on your gateway LAN thats trying to get autoconfigured?.

  • John, I’m willing to believe that, but I don’t know where it would be coming from… not to mention that 10.x.x.x isn’t valid on my LAN, it’s in the 192.168.x.x range. I guess I could go around disconnecting things and see where it’s coming from. other than some PCs, there is a networked printer, a LaCie RAID-1 network storage box, and a Television, which is allegedly turned off (but as we all know you don’t turn them off, really, at least some part is still “on”). last time I looked at the TV config it was properly configured in 192.168.x.x, but perhaps I should go downstairs and take another look.

    … no, it’s not the tv, I just unplugged its cat5 from the jack and the issue didn’t stop.


    hmm… just did traceroute and it comes back as being a system at my ISP. that doesn’t seem right to me. they shouldn’t be broadcaasting such stuff, as far as I know, at least.

    Any other thoughts?

  • the MAC address prefix on that DHCP thing is 00:23:EB which is Cisco… and yes, ISP’s frequently use private IP space for internal gateway networks. they aren’t routable on the public internet, they don’t have to be, they are just used for routes within the ISP’s WAN.

    this is on your eth0 side, I’m assuming thats the WAN side of your firewall/gateway ? if so, then yes, I imagine its something at your ISP, you might ask them what these are.

  • *snip*

    Any network problems, I run Wireshark network analyser in GUI mode. It helps identify issues on the network with meaningfull error and warning messages.




  • you might just try something like…

    tcpdump -i eth0 -w udpdump.txt udp port 67 or udp port 68

    and let that run for a few minutes, long enough to capture a few of these packets, then ctl-C it, and take that dumpfile and load it into wireshark (can do that on any system wireshark runs on) and see what it decodes the dhcp packets to actually be.

    for instance, this is a DHCP ‘renew’ request (from the LAN side of my gateway)…

    # tcpdump -i eth1 -vvv -n udp port 67 or udp port 68
    tcpdump: listening on eth1
    21:46:46.009596 >
    xid:0x9fb275f6 C: [|bootp] (ttl 128, id 31970, len 339)
    21:46:46.013544 >
    xid:0x9fb275f6 C: Y: S: [|bootp]
    (ttl 64, id 16362, len 328)

    2 packets received by filter
    0 packets dropped by kernel

    wireshark will do a much better job explaining the packets than tcpdump does.

  • fred smith wrote:

    I wouldn’t bother.

    Depending on the demarc equipment used by your ISP and how they have their network configured, you can wind up seeing this kind of crap and there’s bugger-all that you can do about it

    For example, with a cable modem, your assigned upstream segment might be network-A, but other people in your neighborhood might be on network-B, both serviced by the same RF carrier. You shouldn’t see unicast traffic for your neighbors, but you could very well see broadcast (and dhcp is the most likely culprit). I know of a particular case where the ISP will assign statics out of one pool, dynamic IPs out of the other pool, a single modem will service machines out of both pools, and therefore you also see broadcast out of both pools.

    This isn’t specific to cable. With both cable and DSL providers I’ve seen both the only-see-your-own-traffic situation and the see-your-neighbors-broadcast situation. It all depends on the equipment and the configuration. And when I mean configuration, I’m talking about for everyone in your node, if not for your whole city. So it’s unlikely that your ISP will change it just for you.

    But if you still want to call them, fill your boots …


  • thanks for the info. I didn’t really expect to get any swift action, I kinda figured “it is what it is, like it or lump it” would be their response. but I still might drop them an email with some log excerpts just to see how they respond. I’m retired, I have plenty of time! :)

  • Those are BOOTP responses from your ISP’s DHCP server to clients requesting an IP address. They have to be broadcast because the client does not yet have an IP address. Go yell at whoever set up your firewall to log these harmless packets that are a necessary part of dynamic IPv4 address assignment on a shared medium.

    SPTg source port = BOOTP server
    DPTh dest port = BOOTP client
    DST% dest address = Broadcast

  • that implies that there are a WHOLE LOT of systems served by this provider that are doing dhcp requests, given the volume of these things I’m seeing. they’re arriving at rates ranging from 4-5 a second, to 1-2 a minute, mostly in the one every 1-5 seconds rate.

    My firewall is filtering them, which is good. and while there are a lot of them it isn’t enough to make a dent in my incoming bandwidth. Were I
    still on dialup or DSL, it might be.

    The firewall is the built-in firewall in my Asus router. the UI doesn’t give much flexibility in what it logs (basically you can log none, dropped, accepted, or all–I’ve chosen to log dropped). Of course, I could open a shell on the router and hack the iptables rules, but I’d just as soon not.

    thanks for the reply!

  • FWIW, I average about 9 of those per minute on my cable segment. That’s
    194000 packets counted by my own (non-logging!) iptables rule in the 15+
    days this system has been up.

  • Welcome to NAT444. Aka ‘double-NAT’ or ‘carrier-grade NAT’ where your connection’s WAN port is further NATted at the ISP’s border router, and the ISP itself is using RFC 1918 space and minimal publicly routable IP addresses.

    There was a special IPv4 address block allocated for this purpose relatively recently; discussion can be found in the NANOG mailing list archives…..