Firewall Block Diagram (Revision 2) Comments?

guardian

This diagram is obsolete - see the revised version here: https://forum.pfsense.org/index.php?topic=126866.msg701462#msg701462

I've never seen any type of diagram of the pfSense firewall, and my inability to visualize what is happening is causing me (and from what I've seen in the forums, a lot of other peple) a lot of problems:

Would I be correct in assuming that a configuration with 6 VLANs, and a WAN would look like this funtionally:

LAN (192.168\. 1.1) -------*FW---|
                                |
VLAN10 (192.168.10.1) ----*FW---|
                                |
VLAN20 (192.168.20.1) ----*FW---|
                                |
VLAN30 (192.168.30.1) ----*FW---|----NAT---FW*---WAN--- (x.x.x.x) Public/Gateway IP
                                |
VLAN40 (192.168.40.1) ----*FW---|
                                |
VLAN50 (192.168.50.1) ----*FW---|
                                |
VLAN60 (192.168.60.1) ----*FW---|

johnpoz

Your use of vlans is a bit confusing. Those would be interfaces, yes you could think of it is "firewall between" any interface and pfsense itself be that a physical interface or a vlan that runs on a physical interface.

guardian

@johnpoz:

Your use of vlans is a bit confusing. Those would be interfaces, yes you could think of it is "firewall between" any interface and pfsense itself be that a physical interface or a vlan that runs on a physical interface.

Thank you for helping me make the language more precise… yes Interfaces.

If I understand correctly: There isn't really any difference between a physical interface or a virtual interface such as might be created by trunking VLANs into pfSense

I have modified the diagram above to include "LAN" and added an "*" to each interface to indicate where filtering occurs.

So any traffic that gets through an interface's firewall (Say VLAN10 for example), will be able to enter any of the other interfaces.

kpa

From the point of the PF packet filter it makes zero difference if the interface is a physical one or a virtual one like VLAN interface or something like a tun(4) or a gif(4) interface, all it sees is layer 3 traffic (the details of how the traffic arrived at layer 2 if at all applicable are lost) and reacts to it according to the rules that have been loaded to it.

guardian

Thanks for the replies… my earlier post was interrupted while I was experimenting... please help me figure this out... my hope is to get this really clear so that all the other poor Noobs don't have to go through the hell that I had to.... I've wasted a lot of time messing around trying to get my firewall config set up because I haven't been able to find clear documentation on the basics of how traffic flows/blocked etc.

If I understand things correctly, the firewall on an interface only filters from the side with the (*). Any traffic that comes through from the other side (without the *) creates a state and will bypass any firewall rules that would ordinarily block it.

Here is a case that I just tried:

VLAN20 - Linux Computer @ 192.168.20.10 - I'll call it tux20
NO FIREWALL RULES AT ALL ont the VLAN20 Interface.
TUX20 can't ping… can't do anything... it's in a jail because the default block rule is triggered. (As expected)

VLAN40 - Linux Computer @ 192.168.40.10 - I'll call it tux40
The VLAN40 Interface has a PASS/ANY/ANY/ANY Rule
tux40, can surf the net, do anything it wants (no surprise)… AND (SURPRISE) ping tux20.
(I would assume that if Tux20 was running an SSH/HTTP service, I would also be able to access it as well-but I wasnt' able to try it.)!

As an experiment I put a BLOCK/ANY/ANY/ANY/ANY rule on VLAN20, cleared the state table and did a did a ping tux20 from tux40.

The ping from VLAN40 to VLAN20 was successful and a new state was created in the state table:

VLAN40 icmp 192.168.40.10:24572 -> 192.168.20.10:24572
VLAN20 icmp 192.168.40.10:24572 -> 192.168.20.10:24572

This seems to be a big contradiction to the normal pf rule "whatever isn't allowed is blocked by default". What gives?

kpa

No no, the filter can do the filtering on both directions. On any given interface the out direction is the traffic leaving the interface and the in direction is any traffic arriving on the interface. If traffic gets passed there has to be a rule that allows that traffic. The only exception you can have is traffic that is generated locally on the firewall and does not leave the system at all, let's say you have the IP address 192.168.1.1 assigned to the LAN interface and you ping that IP from the firewall console the traffic never leaves the system and is not affected by the packet filter (well technically it is but pfSense uses "set skip on lo0" to bypass filtering on local traffic).

The reason why your ping gets trough is that on the "tux40" interface you're allowing incoming traffic and on the "tux20" outgoing is still allowed because that's the pfSense default policy. allow outgoing on any given interface by default. The incoming return ping traffic on "tux20" is allowed by the state created as expected.

Another thing that deserves clarification here is what the default deny policy actually means with pfSense. The rules are structured roughly like this:


...
block drop in inet all label "Default deny rule IPv4"
block drop out inet all label "Default deny rule IPv4"
block drop in inet6 all label "Default deny rule IPv6"
block drop out inet6 all label "Default deny rule IPv6"
...

Those are the default deny rules at the beginning of the ruleset. PF is actually a pass by default type filter so those have to be there to change the default policy to default deny.

The rules that change the default policy for outgoing traffic are then these ones:


...
pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
pass out inet6 all flags S/SA keep state allow-opts label "let out anything IPv6 from firewall host itself"
...

All of those were taken from pfctl -sr output so they are slightly verbose with the flags etc. spelled out.

guardian

Thanks for the response kpa…

Since my objective is to create a good reference document for others (as well as learn this and really understand it myself) I'm going to dig a bit deeper on this. Hopefully I can clarify some things for others that I've found confusing, and some of the more experienced members can help me fill in the gaps or correct errors. I still haven't accounted for NAT, Floating Rules, or localhost in the diagram. (Input here would be much appreciated. I assume things like Unbound and the NTP server are bound to localhost.)

Clearly this is not an easy thing to visualize since it's at least 4 dimensional (since rules have an order to them... i.e float rules, nat rules, etc.)

@kpa:

No no, the filter can do the filtering on both directions. On any given interface the out direction is the traffic leaving the interface and the in direction is any traffic arriving on the interface. If traffic gets passed there has to be a rule that allows that traffic. The only exception you can have is traffic that is generated locally on the firewall and does not leave the system at all, let's say you have the IP address 192.168.1.1 assigned to the LAN interface and you ping that IP from the firewall console the traffic never leaves the system and is not affected by the packet filter (well technically it is but pfSense uses "set skip on lo0" to bypass filtering on local traffic).

The reason why your ping gets trough is that on the "tux40" interface you're allowing incoming traffic and on the "tux20" outgoing is still allowed because that's the pfSense default policy. allow outgoing on any given interface by default. The incoming return ping traffic on "tux20" is allowed by the state created as expected.

I think we may be saying the same thing, but in different ways. Because of the rules pfSense loads, each interface can only filter in one direction. bi-directional filtering is achieved by putting together both the (V)LAN/WAN FW interfaces.

The firewall blocks *–-FW-- that live on the interfaces only operate on traffic flowing from the side with the *****.
For a rule to be of any use, it's SOURCE, must be ANY, or and address on the side with the *****.

For illustration lets look at traffic flows between VLAN20 (in a simple setup this would be LAN) and the internet.
The ISP's gateway is 10.68.0.1, and the ISP's DHCP server assigned 10.68.0.15 to the WAN on pfSense.
A linux box (tux20) has IP address 192.168.20.10 on VLAN20.

The diagram reduces to this.

VLAN20 (192.168.20.1) –--FW---|----NAT--FW----(10.68.0.15)----WAN--- (10.68.0.1) Public/Gateway IP
1--> <--2

Notice that the filters 1 and 2 point in opposite directions. The filter blocks FW are closed by default and don't allow any traffic to flow in the direction of the arrow unless a filter rule is matched. Once a filter rule is matched a "STATE" is created, and any traffic that matches that state will pass and the rules don't come into play until that state is cleared. Any traffic that comes from the opposite side will pass and create a "STATE", passing traffic and suspending rule evaluation for the class of traffic that the state matches.

Filter 1 can only allow traffic out in the direction of the arrow, and Filter 2 can only allow traffic in, in the direction of the arrow. These two filters act as a team to provide bi-directional filtering. Unless there is a rule on the WAN[ [2], nothing can enter the firewall unless a connection "STATE" was first created by outgoing traffic from VLAN20.

Since the default action of the FW blocks is to BLOCK traffic, "BLOCK" rules work is by preventing evaluation of PASS rules. This point is best illustrated by an example.

Consider the following rules:

Firewall / Rules / VLAN20
R1: BLOCK SOURCE 192.168.20.1/24 DEST 8.8.8.8
R2: PASS SOURCE 192.168.20.1/24 DEST ANY
(DEFAULT DROP-ALL OTHER TRAFFIC IS BLOCKED)
Example 1

If tux20 attempts to reach 8.8.8.8, then R1 will match, and evaluation of the firewall rules will stop, and the traffic will be dropped. If the traffic is to any other address, R1 would not match, and rule evaluation would pass to R2, which would match, create a state, and pass the traffic.

We could make our filtering selective by changing R2 to a "White List" alias with allowed destinations.

Firewall / Rules / VLAN20 (MY_LIST is a list of allowed destinations.)
R1: BLOCK SOURCE 192.168.20.1/24 DEST 8.8.8.8
R2: PASS SOURCE 192.168.20.1/24 DEST MY_LIST
(DEFAULT DROP-ALL OTHER TRAFFIC IS BLOCKED)
Example 2

Even if MY_LIST contained 8.8.8.8, R1 would match, and R2 would never be checked, the traffic would be dropped by R1.

If the destination was not contained in MY_LIST, then R2 does not match, we reach the end of the list, and the default action of BLOCK causes the traffic to be dropped.

Note that we can not use (V)LAN rules to block incoming traffic, only outgoing traffic. R1 in the rule set below is useless.

Firewall / Rules / VLAN20 (MY_LIST is a list of allowed destinations.)
R1: BLOCK SOURCE 9.9.9.9 DEST 192.168.20.1/24
R2: PASS SOURCE 192.168.20.1/24 DEST ANY
(DEFAULT DROP-ALL OTHER TRAFFIC IS BLOCKED)
Example 3

An unsolicited connection from 9.9.9.9 appearing on the WAN will be dropped unless there is a rule on the WAN to allow it.

If traffic from 9.9.9.9 doesn't get in, then there is nothing for R1 to match, and it will never do anything.

If traffic is allowed in by a WAN rule from 9.9.9.9, that traffic would be able to enter any (V)LAN it chose because of the direction it is flowing. The filters FW only block packets flowing in the direction of the arrow. Packets going in the opposite direction create a state that passes traffic and deactivates further rule processing for that class of traffic.

Understanding that "States" deactivate rule processing is another very important concept that can be demonstrated with a little experiment. I began with the rules in Example 1, and deactivated R1. I then set a ping 8.8.8.8 running on tux20.

The following states were created: ( Viewed from the menu selection Diagnostics / States / States and Filter expression: icmp and clicking the [FILTER] button.

States created by Ping 8.8.8.8 from VLAN20
Interface Protocol Source (Original Source) -> Destination (Original Destination) State
VLAN20 icmp 192.16.20.10:23073 -> 8.8.8.8:23073 0:0 (s1)
WAN icmp 10.68.0.15:63214 (192.168.20.10:23073) -> 8.8.8.8:63214 0:0 (s2)
WAN icmp 10.68.0.15:31119 -> 10.68.0.1:31119 0:0 (s3)
Example 4

I then reactivated R1 and applied the changes. Because of the states, R1 did absolutely nothing - the ping kept running.

It was only when I killed (s1) by clicking on the little garbage can at the end of the line that the ping stopped dead. (s2) timed out and disappeared soon after I killed (s1).
Oddly (s3) didn't disappear-there were no other icmp states in the table. Anybody any idea why this is happening or how to figure it out?

So an important take away is to make sure that you clear states (either individually like I did, or by selecting the Reset States tab to Reset the firewall state table when you are adding firewall rules, and those rules don't seem to be working. (Keep in mind that Reset the firewall state table will likely drop VOIP calls and interrupt streaming video or file downloads that may or may not resume properly.)

You do make a good point that pf behaves very differently out of the box than pfSense. I didn't know that. pf != pfSense - pfSense loads a ton of rules into pf and wraps a GUI around pf to create is a firewall product. To use a car metaphor, pf is the engine, pfSense is the car. I'm attempting to explain for noobs (and to deepen my understanding) that you turn the key the engine starts, push the gas, car goes, push brake, it stops. What follows is at a different level - like explaining how the battery/starter motor is what makes the engine turn over so it can start…. if the car isn't starting, it's good to know and might give you a hint as to how to get things going, but it won't help you drive under normal circumstances.

@kpa:

Another thing that deserves clarification here is what the default deny policy actually means with pfSense. The rules are structured roughly like this:
...
block drop in inet all label "Default deny rule IPv4"
block drop out inet all label "Default deny rule IPv4"
block drop in inet6 all label "Default deny rule IPv6"
block drop out inet6 all label "Default deny rule IPv6"
...
Those are the default deny rules at the beginning of the ruleset. PF is actually a pass by default type filter so those have to be there to change the default policy to default deny.

This is interesting background as to why the FW blocks behave the way they do. I'm assuming that because they don't have quick in them, these are "last match" rules that don't come into action unless no other rule gets triggered to override them. I have looked at pfctl -sr before and gotten some insight out of it, but some of it is a bit over my head at the moment.

What are inet/inet6? (I know inet is IPv4 and inet6 is IPv6, but other than that I don't have a clue.)

@kpa:

The rules that change the default policy for outgoing traffic are then these ones:


...
pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
pass out inet6 all flags S/SA keep state allow-opts label "let out anything IPv6 from firewall host itself"
...

You totally lost me with these…. can you please explain further.

@kpa:

All of those were taken from pfctl -sr output so they are slightly verbose with the flags etc. spelled out.

I think it was Johnpoz who told me about pfctl -vvsr when I was having a problem with something, and it really helped to see how the rules were ordered. I took another look at the rules and noticed a few things I never noticed before - so thanks for that.

I hope what I've written is clear/accurate…. any input/suggestions are much appreciated.

guardian

As I continue to improve my understanding and develop a model to better visualize the inner
workings of the pfSense firewall, I wanted to share it with the community.

I haven't had a chance to write a detailed text explanation yet, but hope to do so shortly.
This post https://forum.pfsense.org/index.php?topic=126866.msg700593#msg700593
still applies, but it is very wordy and doesn't incorporate the floating rules, but it does illustrate
"State Creation" which might.

pfSense Block Diagram

Sample Firewall with Multiple VLANS
and a Single Internet Gateway

----LOCAL I/F---- FW ---GATEWAY I/F---
IN (I) OUT OUT (O) IN
---> ~F>RF<r< ="" | ="">F>RF<r< <---<br="">LAN ~L>U --> L<u< ="" | ="">L>U <-- L<u<<br>or ~O>L I/F O<l<~@|@~>O>L I/F O<l< wan<br="">VLANx ~A>E RULES A<e< ="" | ="">A>E RULES A<e<<br>~T>S*******T<s< ="" | ="">T>S~~~~~~~~T <s< <br="">Detail of FW Blocks with
Floating Rules

DEFINITIONS

IN/OUT: Direction is always with respect to the interface.
SOURCE: The Initiator of the session to be blocked.
DESTINATION: The recipient of the session to be blocked
I/F RULES: Rules applied on the Firewall / Rules / (LAN,WAN etc.)
Tab for a given interface.
FLOAT RULES: Rules applied on the Firewall / Rules / Floating Tab.

The IP for an interface sits inside the firewall block (FB) and access
to it can be blocked with a firewall rule

Floating Rules are processed before I/F rules, so they can be used to
bypass I/F rules.

Once the firewall block is opened for a session, the rules are no
longer evaluated for that session.

When creating rules that block an open traffic flow, the states
associated with that traffic flow must be cleared before the new rule
will be effective. So either the traffic flow must stop and the
state must time out and clear by itself, or you must use thw WebGUI
to either clear the chosen states, or to clear all states. (Clearing
all states will disrupt streaming traffic and downloads.)

Rules can only block traffic in the direction shown by the arrows
shown with the particular rule. Interface/Normal rules can only block
traffic going into that interface - either from the WAN into pfSense
box, or from a (V)LAN into pfsense as shown.

Floating rules may use one rule to appear on multiple interfaces
simultaneously, and will work as if they were placed on the diagram
as shown.

The key point to remember is to write rules that either block or pass (start) communication between 2 hosts.
Once communication starts, it doesn't matter what the firewall rules are for a given session as the firewall rules
no longer apply to that session. So if someone can open a connection to xxx.com on port 80 they can browse
xxx.com. Attempting to block incoming traffic from xxx.com is useless because xxx.com is not initiating the
session, a machine on the local network is. Instead prevent the connection to xxx.com by placing a reject rule
on the LAN/VLAN - BLOCK Source: ANY (or (V)LAN.net) Destination: xxx.com Ports:80/443.

Can someone tell me does point @@@ have an IP (Layer 3) address?

Any suggestions for how to incorporate NAT and 127.0.0.1 into the diagram?

Suggestions / corrections are welcomed.</s< ></s< ></e<<br></e< ></l<******></l<~@|@~></u<<br></u< ></r< ></r< >