Disallowing access from IP connected to one port of a filtered bridge
-
@bear
I'd rather use member interface filtering to control traffic from different interface.
Rules which should be applied to all members can also be stated on an interface group or as floating.
But I'd also expect yours to work.Maybe an existing state? Did you try to flush states?
Or maybe there's a pass rule above of the block rule allowing access?
To investigate the issue you can enable logging in all rules and see, which is allowing the access in the log then.
-
The rule's been there for months. I only recently got to testing it out, so I don't think there's a flushing that's necessary. There's no pass rule above it. I keep all of my pass rules below all of my block rules.
-
@bear
If you're testing and pfSense passes any traffic it creates a state for this connection.
When you create a block rule after that, the matching traffic is passed anyway as long as the state is there. -
The only rule I've got that MIGHT be overruling these is to allow all traffic from the network out....it's left over from my old config where I wasn't segmenting. Is there a better rule to allow my assigned subnet the ability to get out to the 'net without overriding the other rules?
-
@bear
You can create an alias for RFC 1918 networks and set it as destination with "invert match". So the rule is only applied to non-RFC 1918 destinations.But you can simply move up the block rule to the top, save the order and flush the states.
It's in general a good advice to have rules with the smaller source or destination ranges at the top.
-
Not sure that would work. None of the IPs being used are RFC 1918. They're all public. I have an alias for my public IP block though. Not sure what the best logic would be to redo this rule to allow everything on the network out, but still blocking individual IPs on one bridge meme from contacting another IP on another bridge member.
-
@bear said in Disallowing access from IP connected to one port of a filtered bridge:
None of the IPs being used are RFC 1918. They're all public
Yeah, that's why you should use it in conjunction with "invert match".
-
@viragomann Alright, but that rule would still apply to my internal addresses, as they're non-RFC 1918 destinations. How is that any functionally different than my current rule, or am I missing something?
-
@bear said in Disallowing access from IP connected to one port of a filtered bridge:
Alright, but that rule would still apply to my internal addresses, as they're non-RFC 1918 destinations
I see. I guess, there might be reasons for this. Whatever.
So you need specific aliases of course. -
@viragomann The only thing I can think to do are rules for IP groups that allow them access to everything, and specific bridge firewall rules for the IPs on other network segments that 1) Allow access to anything that is NOT in my subnet (the reverse rule, except using an alias for my /25), and 2) Allow rules for those IPs specifically allowing access to ports on my wired network.
Does that jibe with your logic?
Thanks for the help, BTW. I'm not trying to be difficult. It's just a "different" setup than most use.
-
@bear
If all you want to achieve is blocking access to the Proxmox GUI, why don't you simply put this rule to the top of the rule set.
It is limited to the concerned destination IPs and port, so it should not influence any other traffic.I'm not trying to be difficult. It's just a "different" setup than most use.
In fact. Having wifi and IoT devices within a public IP range seems pretty odd to me.
-
@viragomann said in Disallowing access from IP connected to one port of a filtered bridge:
@bear
If all you want to achieve is blocking access to the Proxmox GUI, why don't you simply put this rule to the top of the rule set.
It is limited to the concerned destination IPs and port, so it should not influence any other traffic.I can try that. But it's only one in a litany of rules. If that works, I'll try moving others to the top of the ruleset.
In fact. Having wifi and IoT devices within a public IP range seems pretty odd to me.
There are only a few wifi devices, and the ones that are there are pretty locked-down. As far as the IOT devices, they're all NATted behind a single IP that's on its own port in the filtered bridge that I'm using rules like the proxmox one to more or less only have Internet access. In that regard, the fact that the IP in front of the NAT is static is immaterial. That also happens to be where my guest network resides.
-
@viragomann I did try moving the original Proxmox rule to the top of my rule set. No difference.
