Firewall logs wan source ip 0.0.0.0 blocked
-
Hello.
I saw these log entries in our Firewall Logs today. I am using pfblockerng and thanks to it I have allowed packets coming from only our country. What do you think, what these source 0.0.0.0 ip addresses mean and why it appears?
Oct 21 15:33:47 WAN 0.0.0.0 Our Public IP ICMP Oct 21 15:33:41 WAN 0.0.0.0 Our Public IP ICMP Oct 21 15:33:38 WAN 0.0.0.0 Our Public IP ICMP Oct 21 15:29:15 WAN 0.0.0.0 Our Public IP ICMP Oct 21 15:29:09 WAN 0.0.0.0 Our Public IP ICMP Oct 21 15:29:06 WAN 0.0.0.0 Our Public IP ICMP -
0.0.0.0 should never be seen as a source IP I would expect it to be blocked. If you click the red "X" in the firewall log you will see what rule has blocked that.
Steve
-
I clicked the red "X" button. It shows:
The rule that triggered this action is:
@56(11000) block drop in log quick on em0 from bogons:10 to any label "block bogon IPv4 networks from WAN" -
Ok, that's what I would expect. You don't have a rule allowing traffic from 0.0.0.0 and there are no states open to it since it's an unroutable address. It should be blocked.
Steve
-
This happens because I have blocked whole world and allowed only our country? Someone tries to ping our network ip and it is blocked, right?
-
That happens because the default behaviour of pfSense is to block all incoming connections on WAN. That would only be passed if you had added a rule to pass it explicitly.
Steve
-
What I don't understand is, I have blocked whole world and allowed only our country. I have firewall logs that show entries from inside our country ip addresses blocked pfsense. Because there are not such ports open. And it shows ip addresses accurately (not 0.0.0.0). Why I got confused of 0.0.0.0, because ip addresses is shown from our country. I also asked someone outside our country to ping and check our ports. He said all attempts shows "Request time out". While he did it, there was no 0.0.0.0 source ip addresses appeared in firewall logs. Then where do these 0.0.0.0 ip address come from?
Oct 21 16:17:41 WAN 5.191.18.128:17062 95.86.128.14:8082 TCP:S Oct 21 16:17:41 WAN 5.191.18.120:51952 My Public IP:8082 TCP:S Oct 21 16:17:39 WAN 5.191.18.120:17062 My Public IP:8082 TCP:S Oct 21 16:17:39 WAN 5.191.18.128:51952 My Public IP:8082 TCP:S Oct 21 16:17:06 WAN 37.27.43.58:43907 My Public IP:8085 TCP:S Oct 21 16:17:06 WAN 37.27.43.58:43906 My Public IP:8085 TCP:S Oct 21 16:15:59 WAN 37.27.43.58 My Public IP ICMP Oct 21 16:15:57 WAN 37.27.43.58 My Public IP ICMP -
No idea. Probably some badly configured device somewhere or someone spoofing their IP. They are correctly blocked though.
Steve
-
There is also another log entry in WAN Firewall Logs.
Oct 21 16:37:54 WAN 192.168.3.80:49184 My Public IP:8080 TCP:RA Oct 21 16:37:54 WAN 192.168.3.80:49184 My Public IP:8080 TCP:FA Oct 21 16:37:54 WAN 192.168.3.80:49189 My Public IP:8080 TCP:RA Oct 21 16:37:54 WAN 192.168.3.80:49189 My Public IP:8080 TCP:FAI cliedk the red "X" button and it shows:
The rule that triggered this action is:
@61(12000) block drop in log quick on em0 inet from 10.0.0.0/8 to any label "Block private networks from WAN block 10/8"
I dont't understand how private ip address can try to open pur port from outside our network.
Both "Block private networks and loopback addresses" and "Block bogon networks" have been checked by default in WAN interface.
-
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.