Firewall logs wan source ip 0.0.0.0 blocked
-
Exactly. Private IP addresses should never be hitting the WAN interface if it has a public IP so there is a rule to drop that traffic.
Potentially it could be from your modem or from some other device on your ISPs network. Though most ISPs should not do that these days.
Steve
-
What is your pfsense WAN connected too? 192.168.x.x is rfc1918 - it will not route on the internet. So that is from the layer 2 network your pfsense wan is connected to either local or upstream via your isp. If your isp is routing that in side their network is another reason you could see such traffic. Or you router/modem/device your wan is plugged into go be using it?
As to IP sourced as 0.0.0.0 you would see that in a dhcp discovery.. ICMP - do you have a vpn setup? that again is going to be from the same layer 2 your wan is connected to. Before APIPA devices use to assign that if they asked for dhcp and didn't get any, etc.
-
I think I have found. We have PBX at our head office. We have also branch office. I have NAT port forwarding rules 5060 UDP for PBX so that branch office can use PBX. And there is an employee with 192.168.3.80 ip address in branch office. I wander how that employee with "private ip address" can try to approach the port of head office, though there is no such port open. If he tries to check our oirt, then it should show brack office public ip, but it shows private ip address.
-
Seem more likely to be a coincidence. Unless you have a bad outbound NAT rule at the branch office maybe.
Do you have anything running at port 8080 they would be trying to access?Steve
-
@johnpoz said in Firewall logs wan source ip 0.0.0.0 blocked:
do you have a vpn setup?
We have vpn running at our head office. I will ask both our ISP and branch office.
-
@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.
