Help on outbound floating rules
-
Hi everyone,
I've been reading a lot on the processing of floating rules now, but I can't seem to understand the behaviour I'm currently getting:
I wanted to create a country whitelist for outbound connections and created aliases using pfBlockerNG and GeoIP from maxmind.
Two things that made this a bit more complicated are:
- I wanted to use floating rules, because we have a lot of internal LAN segments, so adding specific block rules to the all internal interfaces is not an option.
- pfBlockerNG seems to create the GeoIP aliases as "URL Tables", and it seems that I have no way of joining these aliases together into a single alias, which would allow me to use a single rule like "block if destination not in <joined alias>"
My idea was to create a few 'out' rules on my WAN interface "INET" with "quick" off (so last match wins), and reject or block everything first, and then pass a packet when its destination is in any of the whitelists. This looks like so at the end of my floating rule tab:
What I don't get: as soon as I enable the rules, I can't reach some hosts that are definitely in one of the lists. Even more, as soon as I just enable any of the "pass" rules it starts blocking connections and I really don't see how a "pass" rule should ever do this.Could anybody give me the missing details why this behaves so strangely?
Best regards, Rainer
-
@rvjr I don't have an answer offhand, but get the output of "pfctl -sr" that gives you the exact ordering and "quickness" of the rules after application. That makes it easier to understand what is happening (at least for me).
pfSense docs talk about the order in which rules are applied; you have floating rules (applied to one or more interface, in or out or in/out), interface group rules and interface rules. I don't recall what is first/what is last, hence output of pfctl -sr definitely tells you.
If floating rules are applied to an interface, say WAN, before the WAN specific rules and you don't have quick on the floating rules, then the floating rules will evalute first, but then the WAN specific rules will also be evaluated and possibly take precedence.
-
Hi @mer, thanks for the suggestion. I didn't get time to try it out, but now I found that 'pfctl -sr' just says 'pfctl: /dev/pf: Permission denied'. I just executed it as admin logged in via SSH, correct?
-
@rvjr I think that should work as ssh. I've done it via GUI, diagnostics, command prompt stuff.
-
Ok, finally got 'pfctl' working using 'sudo', after installing the corresponding package. I did not dig down into the problem with the rules, but I found another simpler solution: upgrading to the -devel package of pfBlockerNg allows to define combined aliases as described here: https://forums.unraid.net/topic/89659-guide-how-to-allowblock-multi-pfblockerng-geoip-lists-in-pfsense/?do=findComment&comment=984000
I could simply create a single alias and add a negated filter against it to the floating rules tab. This basically solves my problem in a much more elegant way for now. But I'll definitely keep 'pfctl -sr' in mind for debugging rules again if I need it.
Thanks @mer !
-
@rvjr Floating rules outbound on a WAN interface do not work like you may expect. By default they add a "reply-to" to the underlying pf rule which directs returning traffic (traffic which matches the state created by the rule) to the gateway of the WAN interface. Whether this makes sense depends on what your network and destination is like upstream from your WAN interface. You say you lose connectivity for "some hosts" on your whitelist, and I wonder whether the hosts which do work were already passed by an earlier rule, because for the reason I described, you may not receive the reply traffic to traffic which matches a floating 'out' rule.
If you check "disable reply-to" (in the "advanced" section of the rule), then replies to your floating rules 'out' on WAN will come back to your specific WAN host. They will also do this if you change the direction from 'out' to 'both', not because you need the 'in' direction but because 'both' rules do not get a 'reply-to' like 'out' rules do.
I believe pfsense 2.6 added icons on the summary list of floating rules to show direction, and you don't list your pfsense version, so maybe your rules are already 'both' rules, in which case the problem is not (or not only!) the one I described. And I see you've found an alternative solution, but one day it may be useful to understand why the first attempt did not work for you.
-
@msswift oh, wow, that's quite a surprise in terms of functionality :) thank you for taking the time to explain this! I never came across such description in any documentation.
The behaviour you describe could really explain a lot of weird things I've experienced with 'out' floating rules. My initial problem is now solved with the workaround, but I will definitely try 'disable reply-to' or using 'both' instead of 'out' in the next weeks. I will post my findings here then...
Thanks!
best regards, Rainer -
@msswift Thanks; that's a good point. I ran into that a while back when adding a VLAN/VIP to talk to the cable modem that the WAN port is hooked to. Yes, I had added rules that prevent non routable addresses from getting sent out.
-
@msswift THANK YOU. I have spent two days doubting my sanity and reading comprehension trying to solve a problem. Your clean explanation has removed the confusion.
I guess I misread the docs badly. You have helped greatly. Thank you again.
It was the portion stating that replies were sent to the WAN's gateway that helped. I was seeing duplicate packets on wan with one packet having internal addresses. Was not making sense (and was holding up the requirement of full egress control even the fw itself).
Thanks again.