Firewall logs wan source ip 0.0.0.0 blocked
-
@stephenw10 said in Firewall logs wan source ip 0.0.0.0 blocked:
0.0.0.0 should never be seen as a source IP
It's a valid source address, but only for a device requesting a DHCP address and then only until it learns the address. DHCP lease renewals should use the assigned address.
-
Ok I'll give you that.
But not for ICMP hitting your WAN. But valid or not it is correctly being blocked in this context.
Steve
-
Its possible other end of vpn tunnel is doing that?
Devices use to just use 0.0.0.0 if no dhcp and set for dhcp.. Before APIPA came into play. And the whole 169.254 link local stuff
-
Not sure how they would be hitting the WAN IP on the WAN interface if so. Unless there is some mis-connected layer 2 in there somewhere. Which might explain all that.
Steve
-
Yup!
-
@johnpoz said in Firewall logs wan source ip 0.0.0.0 blocked:
Devices use to just use 0.0.0.0 if no dhcp and set for dhcp.. Before APIPA came into play. And the whole 169.254 link local stuff
DHCP works the same as before. The only difference is the link local address is generated if DHCP fails, at least on Windows. On Linux, with the network manager, I have a separate connection configured for link local, as DHCP will just fail. I have no idea about Macs.
-
Agreed when did I say any different? My point was before APIPA then the device would of used 0.0.0.0 if it didn't get an address from dhcp vs the client using a 169.254 address
-
A time ago I had the same issue, never found out what was causing it, but after a while it went away, never to be seen again... Sorry for a useless answer ;-)
-
I usually have this issue, haven't found what causing it yet.
-
What is the mac address of this 0.0.0.0 icmp packet?
-
How can I find mac address of 0.0.0.0?
-
sniff/packet capture on your wan... Open the capture in wireshark.
Or just run a tcpdump with -e should also show it.
Looks like your seeing them every few seconds so you sniff should only need to be very short.
