How to read FW rules in plain English
-
I know this is a super basic question, but I think it will help my brain if I can read a FW rule as if it were a sentence.
I'm hoping it will help me understand how rules work and also help me think through how I need to create new one's when the occasion arrises.Here's how I evaluate the circled rule:
My brain says, "If a packet arrives with a destination of sf.example.com:32400 on the WAN interface, first I need to translate that to the dest IP (is that done with my DNS resolver?)." The answer is that the packet needs to end up at 192.168.2.2 so it bypasses all the rules until it gets to the last one which says, "If packet bound for 192.168.2.2 & port 32400 arrives on the WAN interface via IPv4,TCP from ANY address and ANY port allow it to pass.
Likewise:
If packet enters ETH3 using IPv4,TCP FROM 10.100.10.249 on ANY port and wants to go ANYWHERE, pass.
Is that basically correct? I just want to get better about understanding and building rules.
-
@tknospdr said in How to read FW rules in plain English:
If packet enters ETH3 using IPv4,TCP FROM 10.100.10.249 on ANY port and wants to go ANYWHERE, pass.
Be aware : only TCP, so for example DNS won't work ... (uses UDP)
About
as the 3 rules above this rule, you need to create a NAT rule (not shown).
When you create a NAT rule, a related WAN firewall rule will also be created.@tknospdr said in How to read FW rules in plain English:
"If packet bound for 192.168.2.2 & port 32400 arrives on the WAN interface via IPv4,TCP from ANY address and ANY port allow it to pass.
RFC1918 or local addresses normally never arrive at the WAN interface.
The packets that arrive at the WAN interface will have the pfSense WAN IP as a destination.
From there on, step 1, the firewall rule belong to the NAT rule will apply - so packets can enter.
Step 2 : the actual NAT rule will apply, and do the address/port 'translate trick. -
@Gertjan said in How to read FW rules in plain English:
@tknospdr said in How to read FW rules in plain English:
If packet enters ETH3 using IPv4,TCP FROM 10.100.10.249 on ANY port and wants to go ANYWHERE, pass.
Be aware : only TCP, so for example DNS won't work ... (uses UDP)
Yes, I understand that. My question was if my Firewall to English translation for that particular rule was correct.
About
as the 3 rules above this rule, you need to create a NAT rule (not shown).
When you crate a NAT rule, a related WAN firewall rule will also be created.Yes, this is the FW rule attached to a NAT redirect.
@tknospdr said in How to read FW rules in plain English:
"If packet bound for 192.168.2.2 & port 32400 arrives on the WAN interface via IPv4,TCP from ANY address and ANY port allow it to pass.
RFC1918 or local addresses normally never arrive at the WAN interface.
The packets that arrive at the WAN interface will have the pfSense WAN IP as a destination.
From there on, step 1, the firewall rule belong to the NAT rule will apply - so packets can enter.
Step 2 : the actual NAT rule will apply, and do the address/port 'translate trick.As you pointed out, this is a NAT rule. The packets arrived to the WAN IP and were forwarded to the 2.2 address.
I appreciate your input, but you didn't really answer the question I was asking.
-
@tknospdr said in How to read FW rules in plain English:
Is that basically correct? I just want to get better about understanding and building rules.
Yes that is correct.. That is an any any rule, any port any destination. You have limited it to that IP as the source of the traffic into your interface.. If the source was say 10.100.10.250 then that rule wouldn't match/trigger
Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.
In the case of port forwards, those are evaluated before firewall rules.. But even if you port forward something, there has to be a rule that actually allows it.
-
@tknospdr said in How to read FW rules in plain English:
but you didn't really answer the question I was asking.
I needed to understand the question first.
For example :@tknospdr said in How to read FW rules in plain English:
If a packet arrives with a destination of sf.example.com:32400 on the WAN interface, first I need to translate that to the dest IP (is that done with my DNS resolver?)."
A packet arrives from somewhere on the Internet on your pfSense WAN IP.
On pfSense, at that moment, a NAT/firewall is used to permit the incoming traffic, so it gets send to the 192.168.2.2 LAN device.
This process doesn't use any DNS at all : I didn't understand why you've mentioned "my DNS resolver?". You could stop the resolver at pfSense and your pfSense NAT rule(s) will still work just fine.True, the device you use 'somewhere on the Internet" to connect to your pfSense and/or a device on the pfSense LAN, doesn't (probably) use your WAN IP, but a host name like "sf.example.com:32400". That host name has to be resolved first, as IP connections (and routers, firewalls etc ) can't work with host names. IPs are needed.
The resolving is done on that device and doesn't' use any (your) pfSense services.And yes, you use probably some sort of DynDNS service on pfSense that checks the pfSense (ISP) WAN IP, and it will update your sf.example.com points to "your pfSense (ISP) WAN IP".
And again :
"If packet bound for 192.168.2.2 & port 32400 arrives on the WAN ...No, on your WAN interface you will never see packets with a destination IP 192.168.2.2" ^^
Rule 2, 3 and 4 have the NAT word in the description.
So I wasn't sure that the 5th firewall rule was also a NAT rule. Because, if so, I would have found the NAT word .... that's what I was thinking.Me getting the question right is important before answering anything ;)
-
@Gertjan said in How to read FW rules in plain English:
From there on, step 1, the firewall rule belong to the NAT rule will apply - so packets can enter.
Step 2 : the actual NAT rule will apply, and do the address/port 'translate trick.@johnpoz said in How to read FW rules in plain English:
In the case of port forwards, those are evaluated before firewall rules.. But even if you port forward something, there has to be a rule that actually allows it.
Okay, I'm confused. It sounds like you 2 are saying the opposite. Or is it just your wording.
This relates to the part of my question where I asked:
first I need to translate that to the dest IP (is that done with my DNS resolver?)."It makes sense if what johnpoz said is right, the NAT rule tells the packet that the address needs to change from WAN IP to 2.2. I should have figured that part out myself, but it was late and I was tired when I was puzzling this out.
@Gertjan said in How to read FW rules in plain English:
On pfSense, at that moment, a NAT/firewall is used to permit the incoming traffic, so it gets send to the 192.168.2.2 LAN device.
This process doesn't use any DNS at all : I didn't understand why you've mentioned "my DNS resolver?". You could stop the resolver at pfSense and your pfSense NAT rule(s) will still work just fine.That's the answer I was looking for, I'm a big boy. You can say. "That's stupid, you're not thinking this through. The port forward itself is how pf knows to send the traffic to the 2.2 address.
I'm here asking the question because I want to learn.@Gertjan said in How to read FW rules in plain English:
No, on your WAN interface you will never see packets with a destination IP 192.168.2.2" ^^
Agreed, poorly worded on my part. I should have outright asked how does the packet sent to sf.example.com know how to end up at 2.2. Who knows, my own lightbulb might have gone off at that point.
But I know now, and that's the important part.@Gertjan said in How to read FW rules in plain English:
Me getting the question right is important before answering anything ;)
Fair enough!
-
@tknospdr said in How to read FW rules in plain English:
Okay, I'm confused. It sounds like you 2 are saying the opposite. Or is it just your wording.
In the case of port forwards, those are evaluated before firewall rules.. But even if you port forward something, there has to be a rule that actually allows it.
It's imho, the same.
A NAT rule, the rule part that consist of the WAN firewall rule - the rules you can see on the WAN interface, are handled first, = my step 1.
=> So the traffic can enter te WAN interface.Then comes step 2, this is (imho ^^) more a router rule : the IP and port (NAT or PAT actually) translation is happening.
@tknospdr said in How to read FW rules in plain English:
the NAT rule tells the packet that the address needs to change from WAN IP to 2.2
The rule as a whole, the ones you see here : Firewall > NAT > Port Forward
When you edit a NAT rule, go to the bottom.
You'll find this (example) :
that shows that a NAT rule has a firewall rule linked to it.
The concept of NAT is old, and was created because of necessity. In the beginning, it didn't exist, as "there are 2^32 IP addresses avaible, who needs more ?".
If you have 21 minutes somewhere, look at this one : THE UNTOLD STORY: How the PIX Firewall and NAT Saved the Internet
The video is very well done, and you'll know where NAT came from, and there is a bonus : you'll know where the big player Cisco came from (because they bought the idea, and from then on they moved out of their garage ^^ : they had a device that could do NAT)
And if you know why it is needed, you'll know automatically how it works
( and your one step closer to understand why IPv6 is so great : no more NAT ) -
@Gertjan said in How to read FW rules in plain English:
A NAT rule, the rule part that consist of the WAN firewall rule - the rules you can see on the WAN interface, are handled first, = my step 1.
=> So the traffic can enter te WAN interface.Then comes step 2, this is (imho ^^) more a router rule : the IP and port (NAT or PAT actually) translation is happening.
Okay, I think what was messing me up was my flawed logic again.
Let me attempt to explain what I think you're saying in my own words so I hopefully get it.
Packet arrives to my WAN interface and says "I'm here to see PUBLIC_IP in apartment 3290.
NAT rule says, "Hmm they're actually looking for 192.168.2.2 in apt 32400, but before I send them on their way, let's see if the doorman will allow it"
Doorman says "My rulebook says packets from PUBLIC_IP visiting 2.2:3400 are welcome here"And since it's a secure building, it's allowed to travel between interfaces unless there's an explicit deny in place.
I know I'm mixing the metaphor up a bit, but is that's how I think, I know, you don't wanna be in my brain. But at least there's plenty of room. I'm mostly out of my mind.
And I'll check out that link when I have some free time.
-
@tknospdr said in How to read FW rules in plain English:
Packet arrives to my WAN interface and says "I'm here to see PUBLIC_IP in apartment 3290.
NAT rule says, "Hmm they're actually looking for 192.168.2.2 in apt 32400, but before I send them on their way, let's see if the doorman will allow it"
Doorman says "My rulebook says packets from PUBLIC_IP visiting 2.2:3400 are welcome here"Close !
This order :Packet arrives to my WAN interface and says "I'm here to see PUBLIC_IP in apartment 3290.
Doorman says "My rulebook says packets from PUBLIC_IP visiting 2.2:3400 are welcome here"
NAT rule says, "Hmm they're actually looking for 192.168.2.2 in apt 32400, but before I send them on their way, let's see if the doorman will allow it"Where doorman = the WAN firewall rule (created by the NAT rule).
So, first, an incoming packet has to be allowed by this fire wall rule.
The packet can now enter the router and the attached NAT rule will kick in : it will replace the source IP of the packet with the destination IP for the local LAN IP, like 192.168.1.22. If needed, the original destination port number can also be changed, but this is optional. In your case it was originally '32400' and it sated '32400'.
The NAT rule (and firewall rule) is statefull : the answers from the traffic going to 192.168.1.22 will get remapped in reverse, so a bidirectional data stream can take place.
