Traffic from PFSense itself gets what rules?
-
Howdy people….
Long time user of PFSense (first custom box build in 2012 (Firebox) and several more since including a SG-2240) first time poster...Lets say I have 5 interfaces.... WAN, LAN, OPT1, OPT2, OPT3. On Lan, I have DNS resolver setup and working (well, more on that in another thread maybe). I like to use OpenDNS for filtering, so set systemwide to their IPs. To prevent anyone from hardcoding DNS set a few firewall rules: On LAN, from any to this firewall on port 53 allow, on lan, from any to any on port 53 block. This works as expected.
But how does PFSense itself (since DNS Resolver then does a lookup to OpenDNS) hit the firewall? What interface specifically?
I searched (as I have been doing for 3 years), but this time my google/pfsense-fu skill fail me.
What I suspect is the rules of that interface (lan in this case) apply in this case - using the 2 rules above would result in broken external DNS, and I would need to add a pass rule to OpenDNS as well on LAN. And this would need to be replicated on all interfaces (or floating), but am unsure.
Thoughts smart people?
-
pfctl -sa -
Look at ther rules on the interfaces as rules matching packets coming in on that interface.
Traffic from PFSense itself is already inside, more exactly it's not coming in through any interface, it's going out on WAN if you're looking at pfSense's DNS Resolver querying OpenDNS.
You don't need to add any rule to any LAN/OPT interface for this, since traffic between DNS Resolver and OpenDNS happens only through WAN, and it's initiated by pfSense in outgoing direction. -
pfctl -saWhile I know this is a command I can run in the console, I have no idea what it does. Can you link any docs to it? A ddg search does not find anything useful (some bsd stuff, but nothing specific)
Look at ther rules on the interfaces as rules matching packets coming in on that interface.
Traffic from PFSense itself is already inside, more exactly it's not coming in through any interface, it's going out on WAN if you're looking at pfSense's DNS Resolver querying OpenDNS.
You don't need to add any rule to any LAN/OPT interface for this, since traffic between DNS Resolver and OpenDNS happens only through WAN, and it's initiated by pfSense in outgoing direction.So how does PFsense handle outbound packets in general? I would have thought it would match the inbound rules - but you seem to be saying (my wan does not have a allow anything on it) that anything outbound on WAN goes though - no rules needed. I guess this would make sense - after all almost all traffic would be originating from some interface and you could filter there - but it concerns me that any traffic originating from PFSense in general has no rules.
What if I ran squid on the box? Anything that you could instruct squid to do would go through, right? You would have to make rules in squid itself obviously.
Thanks for the answers, I appreciate it.
-
pfctl -saWhile I know this is a command I can run in the console, I have no idea what it does.
Prints the whole ruleset. https://doc.pfsense.org/index.php/How_can_I_see_the_full_PF_ruleset
-
The normal case for PFSense is only to checks ingress packets and never checks egress packets. Because internal PFSense traffic is not ingress, PFSense traffic never gets checked. I'm pretty sure there are some exceptions to this like creating pseudo-interfaces, but for the most part, PFSense traffic will never get blocked.
-
Thanks both of you - that is very helpful.
-
The normal case for PFSense is only to checks ingress packets and never checks egress packets. Because internal PFSense traffic is not ingress, PFSense traffic never gets checked. I'm pretty sure there are some exceptions to this like creating pseudo-interfaces, but for the most part, PFSense traffic will never get blocked.
Floating rule with Direction set as Out has what sorts of abilities? Assignment (to a queue) but not blocking?
-
Floating rules with direction OUT can be Pass, Reject, Block, or Match. You can set quick or not.
You have to be careful though because OUT rules are post-NAT so you can't specify a local, private address/network as a source because it will not match.
You could use Floating rules direction OUT with a source of This firewall (self) to regulate egress of pfSense-generated traffic, I believe.
-
I think I used it to classify NTP packets originating exclusively from pfSense and not my LAN. I never really figured out the best way to accomplish that scenario.
pfSense did recently add "This firewall (self)” as a src/dst, but I do not know what it defines, precisely.
-
I think I used it to classify NTP packets originating exclusively from pfSense and not my LAN. I never really figured out the best way to accomplish that scenario.
pfSense did recently add "This firewall (self)” as a src/dst, but I do not know what it defines, precisely.
Thinking about it, I believe a floating, outbound rule with a source of This firewall would also match post-NAT LAN traffic.
Like I said, it gets complicated. I have found marking and matching packet tags is the easiest way to positively identify traffic on outbound rules for specific sources.
