Project

General

Profile

Actions

Bug #6799

closed

Negating ``<interface> net`` when a VIP exists on the interface results in unintended behavior

Added by Chris Linstruth over 7 years ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Rules / NAT
Target version:
Start date:
09/20/2016
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.09
Release Notes:
Affected Version:
Affected Architecture:

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.

Actions #1

Updated by Jim Thompson about 6 years ago

  • Assignee set to Anonymous
Actions #2

Updated by Jim Thompson about 6 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.

Actions #3

Updated by Chris Linstruth about 6 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.

Actions #4

Updated by Jim Pingle over 4 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.

Actions #5

Updated by Chris Linstruth over 4 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.

Actions #6

Updated by Jim Pingle over 4 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.

Actions #7

Updated by Marcos M about 2 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

Actions #8

Updated by Marcos M 9 months ago

  • Status changed from New to In Progress
  • Assignee set to Marcos M
Actions #9

Updated by Marcos M 9 months 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
Actions #10

Updated by Kris Phillips 9 months 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.

Actions #11

Updated by Marcos M 8 months ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #12

Updated by Azamat Khakimyanov 7 months 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.

Actions #13

Updated by Lev Prokofev 6 months 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

Actions #14

Updated by Jim Pingle 6 months ago

  • Status changed from Feedback to Resolved
  • Target version set to 2.8.0
  • Plus Target Version set to 23.09
Actions #15

Updated by Jim Pingle 5 months ago

  • Target version changed from 2.8.0 to 2.7.1
Actions

Also available in: Atom PDF