Bug #6799
closed
Negating ``<interface> net`` when a VIP exists on the interface results in unintended behavior
100%
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 7 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 7 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 almost 6 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 almost 6 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 almost 6 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 over 3 years 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
Updated by Marcos M almost 2 years ago
- Status changed from New to In Progress
- Assignee set to Marcos M
Updated by Marcos M almost 2 years ago
- Subject changed from Using NOT (!) with interface subnet macros results unexpected traffic passing when multiple subnets are included in the macro (i.e. VIP subnets) to Negating ``<interface> net`` when a VIP exists on the interface results in unintended behavior
- Status changed from In Progress to Pull Request Review
Updated by Kris Phillips almost 2 years ago
Tested and reproduced. Also tested with patch applied.
Steps to reproduce:
1. Create a LAN rule with Source Any and Destination !LAN Subnets with Allow
2. Create a LAN rule with Source Any and Destination LAN Subnets with Block
Without the patch applied, pinging from a LAN host to the LAN interface IP works, even though the rules above would seemingly mean this should be denied.
Pinging with the patch applied after a manual filter reload, pings to the LAN interface don't work as one would expect based on the syntax of the rules. However, pings to 8.8.8.8 work just fine.
Tested with patch applied/not applied on Aug 4th builds of 23.09.
Updated by Marcos M almost 2 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 85c4a8de0016bc4d192b60fd384af56aa4ba1376.
Updated by Azamat Khakimyanov over 1 year ago
Tested on 23.05_1 and on 23.09-DEV ()
I was able to reproduce this issue on 23.05_1 but on 23.09-DEV adding a VIP on LAN had no effect on firewall rule created on LAN with 'LAN net' alias as a Source.
I would say it should be re-tested one more time when 23.09-DEV becomes next stable version.
Updated by Lev Prokofev over 1 year ago
Works as expected on the current Beta build, VIP has not affected the rules.
23.09-BETA (amd64)
built on Mon Oct 23 20:01:00 MSK 2023
FreeBSD 14.0-CURRENT
Updated by Jim Pingle over 1 year ago
- Status changed from Feedback to Resolved
- Target version set to 2.8.0
- Plus Target Version set to 23.09
Updated by Jim Pingle over 1 year ago
- Target version changed from 2.8.0 to 2.7.1