Disallowing access from IP connected to one port of a filtered bridge
-
@bear said in Disallowing access from IP connected to one port of a filtered bridge:
I've got 3 ports as members of the filtered bridge, with wired servers on one port, WLAN WAP on another, and IOT (NATted) on another.
Any special reason for needing all these on a common L2?
I've written rules to deny access from IPs that are on the WLAN/IOT segments to deny access to IPs that are on the Wired segment in the Bridge Device Firewall rules, however they don't seem to function.
This is a rule written on the Bridge Interface Device which contains the WLAN/IOT/Wired segments.Did you try to put it on the wifi interface?
Or did you configure the Tunables accordingly for filtering on the bridge? -
The tunables are set as shown below.
As far as having them all on the same L2, since I'm using a filtering bridge with enough IPs, I figured using the bridge to filter between physical interfaces made the most logical sense. My IOT devices have a single IP that's the only one on a physical member of the bridge, so my logic is that I can simply deny access to all other devices on the network barring DNS. I'm not sure what I've got configured incorrectly. Rules blocking access from IPs to "This Firewall" work fine.
-
@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.
