Bug #6799
open
Using NOT (!) with interface subnet macros results unexpected traffic passing when multiple subnets are included in the macro (i.e. VIP subnets)
0%
Description
LAN Interface: 172.25.232.1/24
IP Alias VIP on LAN: 10.10.10.10/32
OPT1 Interface: 192.168.1.1/24
Some users like to "block" traffic to LAN net by placing rules like this on other interfaces in place of the typical pass any rule:
pass ipv4 * source OPT1 net dest ! LAN net
This generally works as expected without the VIP on LAN, but the VIP on LAN results in a rule that looks like this:
pass in log quick on $OPT1 inet from 192.168.1.0/24 to { !172.25.232.0/24 !10.10.10.10/32 } tracker 1468440928 keep state label "USER_RULE: Allow OPT1 to any but LAN rule”
This is expanded by pf into:
pass in log quick on re2 inet from 192.168.1.0/24 to ! 172.25.232.0/24 flags S/SA keep state label "USER_RULE: Allow OPT1 to any but LAN rule"
pass in log quick on re2 inet from 192.168.1.0/24 to ! 10.10.10.10 flags S/SA keep state label "USER_RULE: Allow OPT1 to any but LAN rule"
Traffic from 192.168.1.100 to 172.25.232.100 does not match the first rule so QUICK is not triggered.
Traffic from 192.168.1.100 to 172.25.232.100 does match the second rule so it is passed.
The tracker is the same for both rules resulting in misleading information obtained from the firewall log page.
If there is anything else I can add or if this is unclear just let me know.
Updated by Jim Thompson about 5 years ago
LAN Interface: 172.25.232.1/24
IP Alias VIP on LAN: 10.10.10.10/32
You’ve defined LAN here to include both.
So the question seems to be one of POLA violation. Possible that a warning suffixes.
Updated by Chris Linstruth about 5 years ago
Understood.
The usual reason is that is what pfBlockerNG's DNSBL does by default - places a 10.10.10.X IP Alias VIP on the LAN interface.
I believe that VIP should be on Localhost, not an actual interface. Localhost is not an available selection in the DNSBL configuration for the VIP, however. And that would only cover that specific case.
Updated by Jim Pingle over 3 years ago
- Status changed from New to Not a Bug
Adding alias nets to the interface macros was deliberate, so I'd say the only problem here is that pfBlocker won't let you put the VIP on localhost, which isn't a base system issue.
Updated by Chris Linstruth over 3 years ago
I believe that the negate address match rules not "blocking" any traffic is worth a deeper look. This wasn't really a report on the package, but a report on that behavior. That was simply the method that alias was installed on the interface in the first place in that case.
Updated by Jim Pingle over 3 years ago
- Subject changed from VIP outside of LAN subnet results in LAN net expansion causing unexpected traffic to pass to Using NOT (!) with interface subnet macros results unexpected traffic passing when multiple subnets are included in the macro (i.e. VIP subnets)
- Status changed from Not a Bug to New
OK, I was going mostly off the subject + comments which didn't mention the negate specifically. Updated subject.
Updated by Marcos M about 1 year ago
I was able to reproduce this on 22.01 when using macros, but not when using aliases. Regarding pfBlockerNG, the VIP defaults to localhost now.
Perhaps the long-term solution is to use aliases instead of macros in these scenarios.
Docs redmine #12770