Transparent Filtering Bridge 2.0.3 working
-
…but it takes a reboot to update the ruleset ???
Config as per http://people.pharmacy.purdue.edu/~tarrh/Transparent%20Firewall-Filtering%20Bridge%20-%20pfSense%202.0.2%20By%20William%20Tarrh.pdf
-
To be somewhat more specific: Any changes to the FW ruleset have no effect unless the box (ALIX board) is rebooted. It's unclear to me as to why this should be neccessary?
-
only if you're talking about impact on active connections. You have to kill states if you want already-permitted connections to change/be blocked.
-
What I still don't understand then is the case marked with a * below:
Here's the setup:
A=======FW=======B
Here's what happens:
- Station A runs a Ping (ICMP) to station B, which is permitted by the firewall as per rule on the FW interface to A. Ping succeeds.
- Station B runs a Ping (ICMP, too) to station A, which is not permitted by the FW (no rules on FW interface to B). As expected, this one fails.
- I remove the ICMP pass rule on FW interface to A
- The Ping from A to B continues to succeed
- I add an ICMP pass rule on FW interface to B
- The Ping from B to A still does not succeed. This is unexpected.
- The conditions remain for at least 10 minutes (coffee break)
- I reboot the FW
- Ping from B to A now succeeds
- Ping from A to B now fails
-
Firewall rules create in-memory states, that persist until they expire. For as long as the state exists, the traffic will continue to be blocked or passed. Whenever you change firewall rules, and you want to see the effects immediately, you should also reset the states: Diagnostics > States > Reset States > Reset.
-
I agree on one point: If you delete a rule for an existing connection/flow, then the connection/flow will remain active until states are reset (or the state times out).
However I don't agree at all on this: If you add a new rule, you should be able to open a connection (or establish a flow) immediately. Once the first packet comes in, the FW should find the matching rule and thereafter create an entry in the state table and allow packets associated with the connection/flow. A state table reset should not be required for this.
Corroborating my point is the fact that, resetting state tables does not solve my particular problem with this transparent filtering bridge.
Whenever I add or remove a firewall rule, I have to reboot the box to make the rule change effective.Resetting the state table does not change anything.