What is IP address 0.0.0.0

Hi all, as above can anyone perhaps clarify who or what is IP adress 0.0.0.0 in my Firewall logs? I see quite a lot of these entries. Thank you.

In general it is this.

wikipedia article

Perhaps:

A host may use 0.0.0.0 as its own source address in IP when it has not yet been assigned an address, such as when sending the initial DHCPDISCOVER packet when using DHCP.

Edit: Tried to make it more readable. B.

1 Like

@sec-con Thank you for your reply. So, “perhaps” some external device is trying to gain access to my DHCP server? Well, hopefully, it doesn’t happen, LOL!

Well, it could also be one of your own devices. At least in theory.

@sec-con I do not think so ,as the firewall log indicates it is hitting my EXTERNAL IP address, not my internal IPFire network address, so I think that rules out a device on my internal network.

Could you please show an example?

@bbitsch Here you go, although I made one mistake with my comment above, it is not hitting my external IP address:

Looks like there is a MicroTik router with enabled Mikrotik RouterOS Neighbor Discovery Protocol (MNDP) it send broadcasts on 5678

Normal an ISP should not forward this to you.

2 Likes

How is your red network structured, the devices connected to the red0 NIC?

The packets in the log seem to be a kind of DHCP requests on the WAN side, using an unusual port of 5678. Because of the missing IP and network ( source=0.0.0.0, destination=255.255.255.255 broadcast ) I suppose the device is directly connected to the red0 NIC.

@bbitsch The only device connected to my red0 NIC is my ONT unit for my fibre.

With tcpdump you can capture these packets.
WIth
tcpdump -i red0 host 0.0.0.0 -w zeros.cap
you can write it to file zeros.cap, which can be analysed by wireshark eg.

@bbitsch Ah, I see. I will look into doing that later today when I have a moment. Thank you.

This is all whacky. In the DHCP server, if you have DHCP enabled on Green, it still listens on 0.0.0.0. To me this is wrong and it should listen only on green0. If that were so, it wouldn’t respond to DHCP requests on Red. I would have thought this was a bug.

Given that this is what we have, can you set up a firewall rule to filter incoming UDP port 67 on Red? Currently the firewall is open on Green and Red for DHCP by default. Just block incoming DHCP on UDP:67 and not outgoing or your WAN will fail if it gets its address by DHCP.

However, this will probably not fix your issue and is a red herring as you are being hit with packets to UDP:5678. If you have nothing listening on UDP:5678, you have nothing to worry about. Your firewall log has nothing to do with DHCP and it is just an irritant that you are getting so many of these packets.

@nickh Why would I want to create a rule for UDP port 67 on Red? I do not want to compromise my firewall in any way, so please explain your request

I’ve edited my post.

The firewall is open by default to incoming UDP:67 and you seemed to be concerned about DHCP. The firewall rule you would need would be to block inbound DHCP requests, not to allow them, but at the end of the day is a bit of a red herring as it is not applicable to your logs.

@nickh Ah yes, I see you have edited your post, thank you. I’m not really concerned about DHCP, @sec-con and myself were simply speculating where the 0.0.0.0 address COULD be originating from. It has not been confirmed either way, so I am not too concerned about it as it is getting dropped, which is the important part. I was simply wondering where such a strange IP address could be coming from, hence my OP. Thank you.

@nickh ,

this is not true. dhcpd ( the DHCP server ) listen on the enabled interfaces only. By definition a DHCPDISCOVER can only be sent with IP=0.0.0.0, the client doesn’t have one.

Good point. I’d overlooked that.

However I am still not sure why port UDP port 67 is open on Red (and also TCP).

Why do you think port 67 is open on red?
Can you show that?

I was going to say:

Chain DHCPINPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
16351 6146K ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:68 dpt:67
    0     0 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:68 dpt:67

But now I see it is only called by

Chain DHCPGREENINPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
1285K   93M DHCPINPUT  0    --  green0 *       0.0.0.0/0            0.0.0.0/0

This firewall is tortuous with all its chains!