Project

General

Profile

Actions
Copy link

Bug #6799

closed

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

Added by Chris Linstruth about 8 years ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Marcos M
Category:
Rules / NAT
Target version:
2.7.1
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
Copy link

Also available in: Atom PDF