Blocked broadcasts to 192.168.x.255 !?
-
@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
-
