Blocked broadcasts to 192.168.x.255 !?
-
@louis2 what rule is blocking it.. Let see your rules.
Also really what is the point of hiding part of your rfc1918 space?
I use 192.168.9/24 as my lan, pfsense is at 192.168.9.253 - does that give you something you could use to hack me?
Like saying my address is 123, but not giving you the street, the city or the country even.
Are you saying your seeing that on all your different local networks, and X is just a place holder to represent all your networks?
-
John you are true when saying that the "x" is exaggerated, but apart from than, I noticed the issue on my Guest VLAN / sub-net.
The way I define my rule sets is high level like this:
- block rules
- pass rules
- an end block(reject) rule named ^what did I (perhaps unintentionally) block^ with logging activated.
And it is this final rule which generated the message.
If that final rule had not been there, the package had also been blocked, however that would not have been visible.
Perhaps the ^issue^ is simply in line with the way the firewall works / is build:
- the sub-net
- the filter layer
- the gateway itself
And than the confusing thing, the question if the GW is yes or no part of the sub-net.
If the GW is part of the sub-net, then I would assume than any destination belonging to the sub-net would be reaching the GW and that only addresses <> the sub-net would have to pass the filter layer. However it is more and more clear to me, that the GW is "out-side" the sub-net it self. Which would explain e.g. the described "problem"
-
@louis2 said in Blocked broadcasts to 192.168.x.255 !?:
57621^
Likely to be Spotify:-
https://community.spotify.com/t5/Android/Broadcast-Storm-Attack/td-p/5099603
If you don't want to see them block and don't log.
-
@louis2 please just post up a screen shot of your rules. So this is blocked by some rule you created and not the default deny rule.
Actually seeing your rules should be easy enough to figure out why its being block, and how to adjust the rules so its not sort of thing, or not logged, etc.
-
@louis2 said in Blocked broadcasts to 192.168.x.255 !?:
Is there an equivalent IPV6 problem?
IPv6 uses multicast ff00::/8
-
@louis2 said in Blocked broadcasts to 192.168.x.255 !?:
an end block(reject) rule named ^what did I (perhaps unintentionally) block^ with logging activated.
And it is this final rule which generated the message.
If that final rule had not been there, the package had also been blocked, however that would not have been visible.Keep in mind that the last rule for every interface is a hidden one.
You chose if that one should log :
To see your rules, look here : /tmp/rules.debug - looking at that file, and you'll understand why pfSense has a GUI ;)
-
I am 99% sure that the problem is that up to recently I expected the GW to be part of the sub-net and this issue just as two other issues I recently engaged show that the GW is not part of the sub-net.
The filter rules are between the sub-net and the GW which explains why :
- (hidden) rules are needed to reach the local DHCP-server
- and in this case a broadcast is ^hitting^ against the filter rules. (in this case my ^personal^ final rule).
Assuming that the GW / a pfSence local service needs to react on a broadcast ...... that is no problem. The behavoir is just ^strange^ and I will have to add an additional rule to prevent the broadcast events from being logged
-
@louis2 said in Blocked broadcasts to 192.168.x.255 !?:
show that the GW is not part of the sub-net.
Not sure where you got that Idea .. if your network is say 192.168.1.0/24 then the optX net for this network would be inclusive of whatever pfsense lan IP is on that 192.168.1.1 for example and all the way up to broadcast 192.168.1.255
Hidden rules are not "needed" for dhcp - they are created so users don't shoot themselves in the foot.
A simple screenshot of you rules and what is being logged in your firewall that you do not understand and this whole thing would be solved quite quickly I am sure.
edit: Here I created a rule to log traffic to lan net, I then sent ping to the broadcast IP of that "lan net" in my case 192.168.9.0/24
You can see it logged it via that rule
How would pfsense IP 192.168.9.253 not be included in that "net"
-
Of course you do not engage the problem I noticed. My rule sets exactly define what is not allowed / allowed.
Of course every thing will work and being logged if you add the rules in your example. The log rule is passing every thing ..... but that is an added pass-rule ... !!
By adding that rule you order the filter section to pass all local traffic to the GW, however that does not take away the fact ..... that that exactly supports my finding that the GW is behind the filter section.
My final rule is
-
@louis2 A stated a couple of times now - if you would just post up your rules would could all be exactly sure and figure out your concerns.
If you create some rule that blocks everything, and you don't allow for something above then yes it will be blocked, and your case logged..
If I don't have a rule that allows for the broadcast address, then yeah it would be blocked be your catch all rule.
that that exactly supports my finding that the GW is behind the filter section.
Again what? Sorry but if your IP of pfsense - what your calling the gateway is 192.168.1.X/24 and the optX net alias is use it would include 192.168.1.X
So again - please post up your rules and we can put this concern to bed.
-
If I don't have a rule that allows for the broadcast address, then yeah it would be blocked be your catch all rule.
Exactly, and I do not have that rule!!
Because up to recently I assumed that the broadcast address and the GW address, both part of the sub-net, where always passed to the GW and where not stopped by the filter section.
Wrong idea, .... the only conclusion can be that the GW is behind the filter section.
-
@louis2 said in Blocked broadcasts to 192.168.x.255 !?:
both part of the sub-net
They are if you allow "optX net"
That was what I was attempting to show you with my lan net rule.
If you would just post up you rules we could walk through them and explain to you why your seeing the block of the .255, what you could change so you don't, etc.
But any lan net or optX net would include the whole address space of whatever the network is assigned to that interface.. .1-255 for example.
-
John, we agree if I would allow "optX net" or allow "a.b.c.255" it would pass. No doubt about that.
However if you do not add that rule ... then the multicast package in case will hit the rule section and be blocked.
It is not that I am not able to solve that, I was just not expecting that I had to add a rules to let packages pass to the a.b.c.1 or a.b.c.255 address.
So as example the rule set could end like this
- Allowing DHCP
- Not changing any thing to the broadcast behavoir
-
@louis2 again there is zero reason to put in any rules for dhcp.. If you enable dhcp be it ipv4 or ipv6 there are rules that allow that to happen.
multicast is different than broadcast.
What are you concerned with just showing your full rule list.. As long as you don't have any personal relatable names that you don't want tied you say in an alias.. Not understand the issue with showing the full rule list?
For example what possible info is in this rule set that would be of any sort of concern?
edit:
example2Here is a vlan that I see blocked broadcast in my logs, but that is expected and if I didn't want to see it would be easy enough to not log it. But I don't see enough of it to be a concern as log spam, etc..
If I didn't log that rfc1918 space, and the last rule would allow it and not log it, etc.
I personally if I see a lot of broadcast noise that I have no use for - I block it at the switch, same with multicast. Vs just not logging it - why have the noise on the network if I don't have any use for it. If I would need it and just didn't want it in the logs I would redo the rules and logging so I don't see sort of thing.
-
John, hereby my guest rules.
Note that IMHO for FW IPV6-is a crime due to the "unpredictable" source addresses, with as result that filtering on source IP is no option any longer. Filtering on GUEST-net or !GUEST-net is not working (in case IPV6). That is the reason that I did disable the third rule and I assume that your rulesets using "xyz-net" as source selection will not work in case IPV6
Further on see picture below
-
@louis2 first thing why do you have that 169.254 address rule - are you routing that, out of the box that address space doesn't route, and normally the ttl is 1 on traffic from it so it doesn't even route if you even allow for it, etc.
It has 0/0 so traffic has ever been seen.
Your rule 192.168.2.2 to 192.168/16 would block and not log any broadcast traffic to 192.168.2.255
Then the next 3 rules pretty meaning really. No hits on them, not sure what trickyports are - but no hits. But unless you have UPnP enabled on pfsense, that would never be allowed anyway. And if you were going to enable it, you could lock down who could do it in the UPnP settings.
That blocking multicast dns - you understand that would only be to pfsense.. A device on that network can still talk to every other device on that network and discover it. Pfsense has no control over what devices do between themselves on the same network, be it unicast, broadcast or multicast.
Your use of bang rules is would would be causing you to see broadcast from other than 192.168.2.2 which your not logging.
If you just had a block rule above those that blocked access to rfc1918 space and you didn't log it. And then a allow rule any for internet, you wouldn't be seeing the broadcast noise.
Why do you have source as any? Are you using this network as transit, the only real possible traffic that could ever be seen into this interface would be coming from devices on this network 192.168.2/24 Why would you allow all other traffic - doesn't make a lot of sense. Notice on my rules above the source is always the network net of that interface.
-
why do you have that 169.254 address rule
because I noticed that sometimes, even given DHCP availability, that emergency procedure is usedYour rule 192.168.2.2 to 192.168/16 would block and not log any broadcast traffic to 192.168.2.25
I want to assure that the WIFI-repeaters from my networks do not communicate via the WIFIThen the next 3 rules pretty meaning really. No hits on them, not sure what trickyports are - but no hits. But unless you have UPnP enabled on pfsense, that would never be allowed anyway.
-
I disabled Upnp, the idea that a computer is allowed to open FW-ports ..... never
-
Tricky ports is a collection of ports which should never be allowed telnet ..... RPC, netbios etc
That blocking multicast dns - you understand that would only be to pfsense.. A device on that network can still talk to every other device on that network and discover
yep and no. It is only the guest lan and even not that, since the guest network is largely configured as a private lanYour use of bang rules is would would be causing you to see broadcast from other than 192.168.2.2 which your not logging
I do not understand this. Note that 192.168.2.2 is the WIFI Access-pointIf you just had a block rule above those that blocked access to rfc1918 space and you didn't log it. And then a allow rule any for internet, you wouldn't be seeing the broadcast noise.
I fix that at the endWhy do you have source as any?
because- LAN-net is not working for IPV6 (I disabled the rule)
- and I do filter <> LAN-net as one of the first rules (for IPV4)
- also not that it is extra security, but normally spoken other addresses than lan-net should not / can not occur
-
