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
    

  • Netgate Administrator

    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"


  • Netgate Administrator

    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?


  • Netgate Administrator

    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
    

  • Netgate Administrator

    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:FA
    

    I 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.


  • Netgate Administrator

    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


  • Rebel Alliance Global Moderator

    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.


  • Netgate Administrator

    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.


  • Netgate Administrator

    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


  • Rebel Alliance Global Moderator

    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


  • Netgate Administrator

    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


  • Rebel Alliance Global Moderator

    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.


  • Rebel Alliance Global Moderator

    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.


  • Rebel Alliance Global Moderator

    What is the mac address of this 0.0.0.0 icmp packet?



  • How can I find mac address of 0.0.0.0?


  • Rebel Alliance Global Moderator

    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.