Ok ... so I wasn't very happy with having the two tunnables set to one and felt like something was off, so I looked to redo the configuration. Removed all configs from all interfaces, removed the bridge0 interface, deleted the bridge, and sat thinking about it for a while. The tunnable for traffic to be filtered at the member interface makes all the sense to me. I put WAN side rules on the OPT1 interface, and a OPT1_net to any rule on the OPT1 interface. OPT1 and OPT2 are bridged so the DHCP server configured at OPT1 will send broadcasts to all members. So I did that. Configured the /28 on the OPT1 interface, enabled and configured the DHCP server. I also removed the net.link.bridge.pfil_bridge: 1 back to 0. On the firewall added a rule with OPT1 net to any on the OPT2 interface. After configuring OPT1 and DHCP Server, I created a new bridge with OPT1 and OPT2, assigned to a new interface and enabled. After that and inspecting the traffic I saw two things: a rule was needed at OPT2 to allow DHCP traffic; the bridge interface was actively blocking traffic even tho the tunnable is set to zero. Just to make sure, I enabled the DHCP rule on OPT2 first, and waited to see if it would still be blocked on the bridge, and it was. So seems like the option for the bridge doesn't work very well or didn't here. But anyway, after allowing any to any on the bridge, everything is working. So the final config is: opt1 (external)---¡ -> Static IP & DHCP Server enabled | | bridge0 -> firewall allow any to any | opt2 (internal)---! -> Allow DHCP traffic and OPT1_net to any or more granular if preferred. Other rules go on the OPT1 interface like normal In the end I don't know why I overcomplicated cause the final config seemed fairly simple, not sure what was missed before.

@lcs FWIW, I appear to have a similar issue (using v2.6.0). This is caused for me, when I use aliases. So, for example, I had a simple inverted block rule against a single hosts IP address, which worked just as expected. I then needed to extend this rule by adding an additional host, so a created an alias to capture both hosts IP's, then edited the original rule to use the alias rather than the original IP. I actually made a typo in the alias IP, but once it was updated to be correct, the rule was not applied as expected until pfsense is rebooted. Just to test this, I set up a continual ping to a host in another subnet that should match the rule and be allowed to pass. Of course, this did not work, then I rebooted pfsense, as as it came up, so the ICMP message started getting through. I was looking for a way to reload the rule set without rebooting and came across this post.

@johnpoz said in Block all access except one port: I just got an ideea Oh you mean like stated back 2 hours ago Let me rephrase. I just understand your ideea .

@gwaitsi Correct. Reply-to is only needed on WANs (interfaces with a gateway assigned to it).

@eeebbune Page Fault in the Kernel means something happened in the core of the OS the system wasn't happy with.

@furom said in Find out what an ip is used by/for: TCP:PA This happens ... See .. Ie. https://forum.netgate.com/topic/132592/tcp-ra-tcp-a-tcp-pa-blocked/9

@artooro said in Floating Rules Not Applying to pfSense: Floating rules can prevent the firewall from reaching specific IP addresses, ports, and so on." So you want to stop something from leaving the firewall, even the firewall. Then that would be a floating outbound rule on the wan interface.. Really the only rule I do that for being a good netizen is block outbound rfc1918.. So example See the rule in my floating tab.. it is block (red X) on the wan in the outbound direction (see the little arrow in a circle).. It is set as quick (2 double green arrowheads) and it set to log (little hamburger with checkmarks) So I try and ping some rfc1918 address this not on my local networks, so per routing pfsense would send this out the wan. Fails, and is logged as blocked. [image: 1653112921849-block.jpg] Also keep in mind if you tried to do something, that was allowed you would have created a state. Which are evaluated before rules, so yeah blocking something after the state has been created - you really need to make sure no states exist for that traffic before your block rule would take effect. You could either kill any specific states, or all of them. Wait for them to timeout on their own, reboot the firewall is the oh there is a spider in my house, burn down the house response to removing states ;) Now if I disable that rule, see how its grayed out. Now if I ping I just get timeouts.. And notice if I sniff on my wan, traffic actually left the want trying to get to 192.168.42.42 [image: 1653113280194-disabled.jpg] Maybe if you actually gave some details of what exactly your attempting to block we could show rule to do that. Common mistake users make is they test something, it works, then they test it again right after they create a block.. And yeah their rule isn't even evaluated because there was a state already that allowed the traffic, which allowed it - even with your block.

pfsense is incapable of ultrasurf, why is no one answering? :))

@cool_corona said in killing existing (specific) fw states when rule change from disabled to enable: d the dropdown in "schedule" is empty (always none). So, what I'm looking for is that exactly not what I'm looking for :) As mentioned, what I'm looking for is the ability to run a specific task when a rule is enabled or disabled. Not a schedule ! I you want a schedule, go under firewall-> schedule, create your schedule and then go back where you took your screenshot from and assign that schedule :)

@nogbadthebad That's what I mean.. Even though it has different ip range, why it shows me different result, that was my curiousity. It looks like somehow related. Too far to understand PF Firewall for me... Maybe it was just coincidence.. Anyway, thank you for your reply.

@runevn said in How to access nextcloud from another VLAN in a HAProxy+DNS Resolver setup: At the moment my current Nextcloud host overwrite is set to pfsense it self (192.168.1.1). Is that correct? It could be any IP of pfSense. The only requirement is that HAproxy is listening on it. When I add a Vitrual IP for Nextcloud should it be within the same VLAN as the original IP? The same answer. Could be on any interface, but yes for clarity, I would add it to the home VLAN, since you want to access it from devices of this network segment. And what do you mean by "point Nextcloud to this"? I meant to host override with this.

@joanaveryvz would giving this type of exemption apply for troubleshooting non-game retailed clients running on the same machine as your server?

@t1lance24 In case you never figured this out, or someone else stumbles across this on google. You will need 2 rules placed in the “Floating” Rules tab. The first will block return traffic, and the second will be the allow rule. Important note: Both firewall rules must be applied to the same interface. Specifically, they must be both applied to the interface where the traffic is originally coming from (source). Example: Lets say we have a Syslog server at the IP of 192.168.0.10 listening on port 514. And we also have a client that wants to send Syslog messages to the server, and their IP is the 192.168.50.2. So we must allow traffic to pass from the 192.168.50.2 to the 192.168.0.10 on port 514 without allowing return communication. The options you will need set for each rule: BLOCK RESPONSE: Action: Block Interface: WAN #TrafficSourceInterface Direction: Out Protocol: UDP Source: 192.168.0.10 #syslog server Source Port: 514 Destination: 192.168.50.2 #syslog sender Destination Port: any Log: Log packets State type: None ALLOW SYSLOG: Action: Pass Quick: Apply the action immediately on match Interface: WAN #TrafficSourceInterface Direction: In Protocol: UDP Source: 192.168.50.2 #syslog sender Source Port: any Destination: 192.168.0.10 #syslog server Destination Port: 514 State type: none Should look something like below. I have this all configured on an internal firewall, with syslog senders outside my "WAN" so that will differ with other peoples setups. [image: 1652623317935-examplefwrule.png] You can test this out using ncat in udp mode between two machines. Thats originally how I figured it out.

@steveits Hey Steve, Despite having a mixed setup (network setup on the virtualised physical ports and Internal Private Network) on our live server that seems to be working seamlessly, things didn't seem to want to work on the exact same server with test machines. LAN seemed to be working on the physical port and the External connection on the Internal Private Network port. It seems like a pretty hatchet job, but it is all working. I tried setting up the LAN on the physical port for the test machine and it didn't like it. So I ended up with the pfSense WAN on the physical port and the LAN on the IPN. Then I switched the network on the test machine from the physical port to the IPN. It now appears to work (logically it should) and I am happy. It has been quite a headache and has set me back and entire week. I was hoping to be dropping the server into the DC about 4 hours ago and confirming everything was working before finalising the swap and turning the other server off. I did expect that using the physical port should work, as it's an active connection on the switch. It is however a managed switch, so I am unsure of their setup. But the current LAN connections did seem to work when using the physical port. Oh well, I guess don't look a gift horse in the mouth... it works and I will just go with it. Just had another thought... maybe openvswitch is installed on the live Server (I think it may have been by default on that version) and not on the new Server. But thanks for throwing some ideas out there to help :)

@underworld said in VLans, Subnets, Block rules: my understanding is that you can't access those other IP ranges in the different subnet, making the blocking from firewall pointless? Huh? How would the internet work if could not access other IP ranges?