Project

General

Profile

Bug #6799

Using NOT (!) with interface subnet macros results unexpected traffic passing when multiple subnets are included in the macro (i.e. VIP subnets)

Added by Chris Linstruth over 3 years ago. Updated 8 months ago.

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

0%

Estimated time:
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.

History

#1 Updated by Jim Thompson about 2 years ago

  • Assignee set to Steve Beaver

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

#3 Updated by Chris Linstruth about 2 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.

#4 Updated by Jim Pingle 8 months 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.

#5 Updated by Chris Linstruth 8 months 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.

#6 Updated by Jim Pingle 8 months 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.

Also available in: Atom PDF