Firewall(self) as source in rules?
-
When trying to directly translate the rules, you should try to recreate the logical intent. Those rules ensure that you can access the firewall on port 22 from LOC and NET. The pfSense equivalent would be to allow all to LOC Address on port 22, and allow all to NET Address on port 22. Usually the default LAN has an Allow All rule so you would really only need to set the rule on your LOC interface (assuming NET is your default LAN).
-
Okay, I got most of the rules down after intensive researching and help above. Still hadn't gotten my question answered, that is if I can make the Firewall(self) as a source? Another example will be allowing SMTP from Firewall to NET. Unless I don't need to?
-
I must put it in this firewall via pfsense 2.0.
pfSense 2.0 doesn't have This Firewall (self). It was added in 2.2.
Packets from pfSense itself are generally passed since the packets are originating inside pfSense so it makes a lot more sense to use it as a destination than a source.
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting
-
don't use 2.0 … it's ancient and unsupported
-
Whoops, sorry. I meant 2.2, just had to fetch the documentation for the firewall to double check.
I must put it in this firewall via pfsense 2.0.
pfSense 2.0 doesn't have This Firewall (self). It was added in 2.2.
Packets from pfSense itself are generally passed since the packets are originating inside pfSense so it makes a lot more sense to use it as a destination than a source.
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting
Okay, so in that case, is there a way to specific DHCP requests, NTP connections or DNS connections FROM the firewall to a network in the rules?
-
Okay, so in that case, is there a way to specific DHCP requests, NTP connections or DNS connections FROM the firewall to a network in the rules?
Huh? A way to what?
Did you even read that link?
-
In theory, you could use packet marking to mark packets originating from LAN, then create 2 floating rules for outgoing WAN packets. One rule catches the marked packets from LAN and the other will catch packets originating from pfSense. Be careful with the order of floating rules as the last rule matched is the rule that is applied (unlike "first match" with Interface or "Quick" rules). So, the order should go from broadest rule (top) to the most precise rule (bottom).
If you use outgoing NAT, be aware that outgoing packets on WAN will have translated the source address from LAN to WAN IP.
-
@KOM:
When trying to directly translate the rules, you should try to recreate the logical intent. Those rules ensure that you can access the firewall on port 22 from LOC and NET. The pfSense equivalent would be to allow all to LOC Address on port 22, and allow all to NET Address on port 22. Usually the default LAN has an Allow All rule so you would really only need to set the rule on your LOC interface (assuming NET is your default LAN).
As well as logical intent in terms of what the rule was supposed to achieve in a firewall sense, remember to consider the intent from a human sense. Why do they want port 22 to be able to access the firewall from both LOC and NET? I've had no experience with Shorewall but from the looks of it, configuration would be done over port 22 on the command line. PFSense's configuration is done via the web interface so while port 22 might still be useful (status checks, ping from the box etc) interpreting the intent of this rule would also mean making sure PFSense's administration page was accessible from both LOC and NET. And you should probably make sure it was locked down to HTTPS.
-
Okay, so in that case, is there a way to specific DHCP requests, NTP connections or DNS connections FROM the firewall to a network in the rules?
Huh? A way to what?
Did you even read that link?
My apologies, I did not mean to frustrate people here. I am still figuring out how to translate rules though I am almost done with just a few rules left. What I meant from that question was part of the rules sheet that I got.
I just need to make rules for:
Accepting DNS connections from Firewall to the network
Allow DHCP request from firewall to campus network
Allow ports 80 traffic FROM firewall itself for apt
Allow email from firewall out.Just a few of the many left but the idea stands, they all originate from Firewall in the rules and since I am so inexperienced in this kind of stuff, I feel I need to turn to this forum for some help. I was able to easily make rules that involved opening ports to the firewall as a destination though I'm not sure about the other way around.
-
I just need to make rules for:
Accepting DNS connections from Firewall to the network
Allow DHCP request from firewall to campus network
Allow ports 80 traffic FROM firewall itself for apt
Allow email from firewall out.Why? All of this just works out of the box (unless you have screwed it via some badly designed floating rules).
-
Again, did you even read that link?
-
i think whoever gave you that sheet with the current "linux' firewall rules, probably has no clue how a firewall should work, and made an overcomplicated mess of things.
do note that i personally know (almost) nothing about firewalling :)
