Keeps blocking



  • Apr 14 11:00:17 	WLAN 	Default deny rule IPv4 (1000000103) 	192.168.5.65:50865		123.56.235.35:28622		TCP:RA 
    
    Apr 14 11:34:51 	WLAN 	Default deny rule IPv4 (1000000103) 	192.168.5.68:54254		184.50.166.121:443		TCP:RA 
    

    I keep getting blocks although I have removed all possible block rules, also disabled pfBlockerNG, the DNSBL and reset the states, maybe someone can help?

    Cheers Qinn



  • Rebel Alliance Global Moderator



  • @johnpoz:

    https://doc.pfsense.org/index.php/Why_do_my_logs_show_"blocked"_for_traffic_from_a_legitimate_connection

    This ? comes up every couple of days..

    Thanks for your help Jhon, Yes I found that one too (M0n0Wall that's a long time ago), but how can I distinguish them from real blocks?

    <off-topic>When I start the IGMP proxy between WLAN interface and WLANGuest, I get

    Apr 14 13:10:04 	WLAN 	Default deny rule IPv6 (1000000105) 	[fe80::144e:9527:a03d:293]:5353		[ff02::fb]:5353		UDP 
    
    Apr 14 13:09:22 	LAN 	Default deny rule IPv6 (1000000105) 	[fe80::3126:68f3:b35:9966]:1900		[ff02::c]:1900		UDP 
    

    are they the same as above as I don't understand why they are because the rules allow to any and there is even a block on the LAN interface, Yet,  it's not in the IGMP proxy config?</off-topic>


  • Rebel Alliance Global Moderator

    that is multicast traffic and pfsense is not going to route that traffic.

    They are not the same as above.. you can tell from simple looking at the dest addres that its multicast traffic.  The first traffic was RA on the flags, which RST,ACK - which screams out of state traffic.

    If you do not want to see such noise in your logs, then allow it so its not logged via a rule with that dest.  Turn off default logging.. Create a rule that blocks it and doesn't log it.

    If you turn off default logging, then you can create rules that only log what you want, etc.

    Thee are many ways to skin the cat of not seeing multicast noise in your default deny rule.



  • @johnpoz:

    that is multicast traffic and pfsense is not going to route that traffic.

    They are not the same as above.. you can tell from simple looking at the dest addres that its multicast traffic.  The first traffic was RA on the flags, which RST,ACK - which screams out of state traffic.

    If you do not want to see such noise in your logs, then allow it so its not logged via a rule with that dest.  Turn off default logging.. Create a rule that blocks it and doesn't log it.

    If you turn off default logging, then you can create rules that only log what you want, etc.

    Thee are many ways to skin the cat of not seeing multicast noise in your default deny rule.

    I don't understand everything you are saying yet, I understand that it's Multicast traffic. I thought that with the ip options enabled in a pass rule they would not appear in the logs as they are not blocked anymore, what am I missing (hope it's not a lot  ;) )

    …and why am I seeing it (multicast traffic) even on subnets (only when I enable the IGMP proxy) that are not in the config of the IGMP proxy? Does pfsense do this, because I enabled the IGMP proxy? below is a ipv4 multicast address from a subnet that's not in the IGMP proxy?

     	Apr 14 15:10 	P2P 	192.168.2.20 	224.0.0.22
    

  • Galactic Empire

    @Qinn:

    <off-topic>When I start the IGMP proxy between WLAN interface and WLANGuest, I get

    Apr 14 13:10:04 	WLAN 	Default deny rule IPv6 (1000000105) 	[fe80::144e:9527:a03d:293]:5353		[ff02::fb]:5353		UDP 
    
    Apr 14 13:09:22 	LAN 	Default deny rule IPv6 (1000000105) 	[fe80::3126:68f3:b35:9966]:1900		[ff02::c]:1900		UDP 
    

    are they the same as above as I don't understand why they are because the rules allow to any and there is even a block on the LAN interface, Yet,  it's not in the IGMP proxy config?</off-topic>

    fe80:: != WLAN net address even if it originates from the WLAN net, thats why its hitting the default block rule and logging.



  • @johnpoz:

    that is multicast traffic and pfsense is not going to route that traffic.

    They are not the same as above.. you can tell from simple looking at the dest addres that its multicast traffic.  The first traffic was RA on the flags, which RST,ACK - which screams out of state traffic.

    If you do not want to see such noise in your logs, then allow it so its not logged via a rule with that dest.  Turn off default logging.. Create a rule that blocks it and doesn't log it.

    If you turn off default logging, then you can create rules that only log what you want, etc.

    Thee are many ways to skin the cat of not seeing multicast noise in your default deny rule.

    What would be an example of and allow rule, as they are hogging up the logs or would you advise otherwise?


  • Rebel Alliance Global Moderator

    Are you using ipv6.

    The default allow ipv6 rule would prevent the logging if changed to any as source.  I think NogBad is correct in that the fe80 link local is what is flagging it to be dropped because it does not = the ipv6 net on your wlan interface?

    Comes down to are you using ipv6 or not to the best way to remove this sort of noise from the logs.



  • @johnpoz:

    Are you using ipv6.

    The default allow ipv6 rule would prevent the logging if changed to any as source.  I think NogBad is correct in that the fe80 link local is what is flagging it to be dropped because it does not = the ipv6 net on your wlan interface?

    Comes down to are you using ipv6 or not to the best way to remove this sort of noise from the logs.

    Apr 15 15:28:13 	WLAN 	Default deny rule IPv6 (1000000105) 	[fe80::1885:465b:bf10:40b6]:5353		[ff02::fb]:5353		UDP 
    

    I tried adding it to the allow but it still keeps hammering the logs (pulling my hairs out  :( ).

    I don't quit understand what you and @NogBad mean to say. Could you give and example or point out what I am not doing or doing wrong in my firewall rules to get rid of it.



  • Rebel Alliance Global Moderator

    your rule to dest ff02:fb should work other than your source is set o wlan net.. which is not what the source is fe80 is not wlan net.  Set the source to any ipv6 on that rule and it should stop your log spam..

    If you don't want to set any for the source, set it to the link local prefix FE80::/10



  • @johnpoz:

    your rule to dest ff02:fb should work other than your source is set o wlan net.. which is not what the source is fe80 is not wlan net.  Set the source to any ipv6 on that rule and it should stop your log spam..

    If you don't want to set any for the source, set it to the link local prefix FE80::/10

    That worked, your a lifesaver jhonpoz 2 thumbs up  ;)

    Apr 15 16:57:33 	WLAN 	Default deny rule IPv6 (1000000105) 	[fe80::5c94:2cc1:5329:99c4]:546		[ff02::1:2]:547		UDP 
    

    I looked at Wireshark and saw the mac address, looked at the DHCP server (as it serves IP on mac address) and found it to be a Labtop. Is there any other way I could have looked it up an easier way, preferably using pfSense and not Wireshark?

    I still don't understand why WLAN as source did not work, could you point that out to me?



  • Rebel Alliance Global Moderator

    Because your wlan net is say 192.168.1/24 or whatever your IPv6 global network is you got from your ISP or HE tunnel you setup, etc.. say 2001:470:xxxx::/64

    fe80::XXXX is not your IPv4 or your IPv6 network, its a link local address that does not fall under your "net" listings for your different interfaces.

    You could of just done your sniff on pfsense for that dest port if you wanted to find the mac of what was sending it.. Just set the level to FULL and it would show you the mac in the output.



  • @johnpoz:

    Because your wlan net is say 192.168.1/24 or whatever your IPv6 global network is you got from your ISP or HE tunnel you setup, etc.. say 2001:470:xxxx::/64

    fe80::XXXX is not your IPv4 or your IPv6 network, its a link local address that does not fall under your "net" listings for your different interfaces.

    You could of just done your sniff on pfsense for that dest port if you wanted to find the mac of what was sending it.. Just set the level to FULL and it would show you the mac in the output.

    I'd missed that setting, were can I set it to Full?


  • Rebel Alliance Global Moderator

    In the packet capture settings when you do the capture… Its right there next to the start but - kind of have to be blind to miss it.




  • @johnpoz:

    In the packet capture settings when you do the capture… Its right there next to the start but - kind of have to be blind to miss it.

    LOL  ;) Maybe Yesterday, I was not the sharpest knife in the drawer, but getting sharper by every post!

    Could you advise on my rule-set, as I already have 3 rules now for multicast, I would like to catch all multicast ipv6 and ip4 addresses or is that not wise?

    btw under advanced options should not be enabling Allow IP options not be a thing?



  • Rebel Alliance Global Moderator

    pfsense is not going to do anything with multicast unless your running the igmp proxy?

    If you do not want to see the log of such noise its almost easier to just turn off default logging and create the rules to log the traffic you want to see.  Say tcp syn only packets.

    You could combine those 3 rules into one by just using ff02::/16



  • @johnpoz:

    pfsense is not going to do anything with multicast unless your running the igmp proxy?

    If you do not want to see the log of such noise its almost easier to just turn off default logging and create the rules to log the traffic you want to see.  Say tcp syn only packets.

    You could combine those 3 rules into one by just using ff02::/16

    I'm quit lost when it comes to CIDR (but there are calculators enough around) and Multicast is not really my thing, but as I need to give phones and tablets control over Sonos devices that are in different VLAN's, I have a IGMP proxy setup (don't want IGMP snooping using a switch). I also have the Avahi service running as Bonjour printers are also in a different VLAN. So suddenly, I am confronted with IPv6 and Multicast…

    If I would like to follow your advise are there examples "better a good copy, than a bad original"