Hi,
I've been digging through the auto-generated floating rules and also looking at the BSD documentation for PF.
I'm not sure about a few points:
1) If a rule doesn't specify an interface, does it apply to all interfaces by default - including any WAN/pppoe interfaces? I'm specifically looking at the auto-added ICMPv6 (RFC4890) and CARP rules which look like they would allow traffic that I don't want in on my WAN interface. I don't use IPv6 or CARP.
2) When you disable "Allow IPv6", it looks like it adds a "block all IPv6" floating rule which is "quick" and appears in the list before any of the RFC4890 rules. Does this mean it will take precedence and block all ICMPv6 traffic? Referring back to question 1: does this mean if you don't uncheck "Allow IPv6" it will mean the ICMPv6 RFC4890 traffic will (by default) be allowed in on the WAN interface? Or is there some other mechanism preventing this traffic ingress on WAN?
3) The floating rules are assessed before any other rules correct? I can't see any other rules which would restrict CARP traffic on the WAN interface for example. The default drop rules for IPv6 and IPv4 aren't quick and so the quick CARP rules would take precedence from what I can see.
It's also entirely possible that I've confused myself here digging through all sorts of forum posts and BSD PF documentation all morning :)
At the end of the day, I just need to know that the WAN interface is locked down - I don't allow anything initiated from outside into my network - no open ports etc.
Thanks.
1. That sounds right. You can check out the detail of the rules under Firewall/Diagnostics/PfInfo/Rules. ICMPv6 is essential to the functionality of IPv6 and therefore is needed on the WAN interface if using IPv6
2. Yes, the block rule will be evaluated and applied first and therefore will prevail
3. Yes, the order of rule evaluation is explained in the OPNsense docs - Floating>Groups>Interfaces. If a rule is non-quick, it will be evaluated but not applied unless it is the last-matching rule
Thanks for the reply.
I've just done a fresh install of 21.7 to see what the default out of the box rules are and I still notice on an output from pfctl -s rules:
block drop in log quick proto carp from (self) to any label "306...<shortened for clarity>"
pass log quick proto carp all keep state label "ace..<shortened for clarity>"
The second pass rule that concerns me as I presume it will allow CARP traffic on all interfaces including the WAN interface? I don't have CARP enabled and can't seem to find a way to remove this - short of editing the filter library file which I don't want to do.
Is this a bug and if so, should I raise a ticket?
I don't even think I can add in a floating rule that overrides this to block it as I can't guarantee that it will have higher precedence than the above quick rule. Do two identical quick rules: one for block and one for pass have some sort of default behaviour where most restrictive wins or is it the order of the rules that counts?
(was: Floating rules confusion: CARP and IPV6)
Anyone?
I've looked into this more and looking at /usr/local/etc/inc/filter.lib.inc, the block rule that's enabled when CARP is switched off is defined here:
// CARP defaults
$carp_disabled = empty($config['hasync']) && empty($config['virtual']['vip']);
$fw->registerFilterRule(
1,
array('protocol' => 'carp', 'descr' => 'CARP defaults', '#ref' => 'system_hasync.php', 'from' => '(self)', 'direction' => 'in', 'disabled' => !$carp_disabled).
$defaults['block']
);
...
However, this is only blocking from (self) which is any IP address assigned to any interface. On the WAN, that's not enough to block incoming traffic from the Internet to IP 112 (carp)..
As I mentioned, I'm no expert with CARP but surely this rule should/could be tweaked to block in/out traffic from any address to any address?
I'm happy to be corrected but will raise a ticket for this if I am indeed correct. :)
carp traffic uses non routable multicast traffic (destination 224.0.0.18, https://en.wikipedia.org/wiki/Multicast_address). Originally we started with the following two rules when carp was enabled:
block in quick proto carp from (self) to any
pass quick proto carp
https://github.com/opnsense/core/blob/92dbe83e75637f478697abfbaaaf8bd3a424e846/src/etc/inc/filter.inc#L3428-L3431
Eventually the first (block) rule translated into being discarded, which wasn't really intentional, but likely doesn't change much either since the source address doesn't really matter to determine which machine has the highest priority.
Looking into the origin of the block rule https://github.com/pfsense/pfsense/commit/986a3accd40a7d45c0a3d48d2b42d2c58a231d99
and https://redmine.pfsense.org/issues/598 one could argue that deleting it wouldn't be an issue at all... we've never seen these issues in the years we accidentally disabled it...
Best regards,
Ad
Thanks a lot Ad! :)