Filtering bridge with pf.

[Carsten Sonne Larsen]

Hello guy,

I am using pf to implement a filtering bridge but Im experinces some
strange behaviour from pf. While using tcpdump I get entries like this:

16:25:45.998253 rule 2..16777216/0(match): block in on rl0:
192.168.0.1.32768 > 239.255.255.250.1900: UDP, length 339

I am using the keyword *quick* and would expect a certain rule match
instead of rule 2..16777216

Also using pftop for some reason states does not expire while looking in
the rules view.

Could this be due a miscompiled kernel or maybe simply a faulty
configuration ? Im using 9.1 on a AMD Geode CPU.

Thanks in advance.

Carsten Sonne Larsen

_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"

[wishmaster]

--- Original message ---
From: "Carsten Sonne Larsen" <c...@innolan.dk>
Date: 4 April 2013, 17:49:07


> Hello guy,
>
> I am using pf to implement a filtering bridge but Im experinces some
> strange behaviour from pf. While using tcpdump I get entries like this:
>
> 16:25:45.998253 rule 2..16777216/0(match): block in on rl0:
> 192.168.0.1.32768 > 239.255.255.250.1900: UDP, length 339
>
> I am using the keyword *quick* and would expect a certain rule match
> instead of rule 2..16777216
>

Hi.

What is your sysctl's?

Below from my production server with 3 NIC's in bridge. I use filtering only on the bridge0 interface.

net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.pfil_bridge: 1
net.link.bridge.pfil_onlyip: 1

and set skip quick on [[members]] in pf.conf.

[Michael MacLeod]

Without seeing the ruleset in question it's hard to say, but if rule 2 also
uses the quick keyword, then it won't reach the certain expected rule you
mention. Again, hard to say without seeing at least rule 2 and the expected
rule, and better the whole ruleset.

On Thu, Apr 4, 2013 at 10:35 AM, Carsten Sonne Larsen <c...@innolan.dk> wrote:

> Hello guy,
>
> I am using pf to implement a filtering bridge but Im experinces some
> strange behaviour from pf. While using tcpdump I get entries like this:
>
> 16:25:45.998253 rule 2..16777216/0(match): block in on rl0:
> 192.168.0.1.32768 > 239.255.255.250.1900: UDP, length 339
>
> I am using the keyword *quick* and would expect a certain rule match
> instead of rule 2..16777216
>
> Also using pftop for some reason states does not expire while looking in
> the rules view.
>
> Could this be due a miscompiled kernel or maybe simply a faulty
> configuration ? Im using 9.1 on a AMD Geode CPU.
>
> Thanks in advance.
>
> Carsten Sonne Larsen
>

> ______________________________**_________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-pf<http://lists.freebsd.org/mailman/listinfo/freebsd-pf>
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@**freebsd.org<freebsd-pf-...@freebsd.org>

[Thomas Steen Rasmussen]

On 04-04-2013 16:35, Carsten Sonne Larsen wrote:
>
> I am using the keyword *quick* and would expect a certain rule match
> instead of rule 2..16777216
>

It has been like this since FreeBSD 9 I believe, and the situation
is the same in the new smp pf from head. I don't know what causes
it, but just to let you know it is not related to your specific ruleset.

I also use the "quick" keyword on all my rules if that helps.


Best regards,

Thomas Steen Rasmussen

[Kimmo Paasiala]

On Thu, Apr 4, 2013 at 9:56 PM, Thomas Steen Rasmussen
<tho...@gibfest.dk> wrote:
> On 04-04-2013 16:35, Carsten Sonne Larsen wrote:
>>
>> I am using the keyword *quick* and would expect a certain rule match
>> instead of rule 2..16777216
>>
>
> It has been like this since FreeBSD 9 I believe, and the situation
> is the same in the new smp pf from head. I don't know what causes
> it, but just to let you know it is not related to your specific ruleset.
>
> I also use the "quick" keyword on all my rules if that helps.
>
>
> Best regards,
>
> Thomas Steen Rasmussen
> _______________________________________________

I believe this is the same what you see with the UDP broadcast traffic
that SAMBA uses. Basically the interface that is used to send the
broadcast also receives the same broadcast because it's in same
broadcast domain. That's why the log entries say "block IN on..." with
the source address in the packet matching the address bound to the
same interface.

To OP: Are you using antispoof on the interface? That would explain
the log entry I think.

-Kimmo

[Carsten Sonne Larsen]

Thanks for the replies.

I also run a 3 NIC setup. I do the filtering on interfaces to control
directions, eg. what goes in and what goes out.

The sysctl are:
net.link.bridge.pfil_bridge=1
net.link.bridge.pfil_member=1

Im not sure why I didnt add the two other lines. I think I followed chapter 38 of the FreeBSD Handbook. I did omit ALTQ_NOPCC while compiling the kernel though.

Rules are maybe not so well formed. Examples are:
...
block log on $ext_if all
block log on $int_if all
block log on $mgt_if all
pass in quick on $int_if inet proto tcp from $ext_ip2 to any keep state
pass out quick on $ext_if inet proto tcp from $ext_ip2 to any keep state
pass in quick on $int_if inet proto udp from $ext_ip2 to any keep state
pass out quick on $ext_if inet proto udp from $ext_ip2 to any keep state
...

antispoof is only specified for the management interface.

I run some other instances of pf, but not in bridge mode. All are deployed with 8.3 and they work perfectly fine. tcpdump on those shows up like:
rule 25/0(match): block out on em1 ...

-cs

[Carsten Sonne Larsen]

After reading carefully through the man pages of if_bridge, sysctl's are
now:
net.link.bridge.pfil_onlyip=1
net.link.bridge.pfil_member=1
net.link.bridge.pfil_bridge=1
net.link.bridge.pfil_local_phys=1
net.link.bridge.ipfw=0
net.link.bridge.ipfw_arp=0

Statistics with pftop and "pfctl -vs rules" still shows an accumulated
number of states. Also tcpdump still shows a rule range instead of a
fixed rule number, while pftop shows * in the rule column. Nevertheless,
the bridge seems to work as intended.

>
> On 04/04/2013 19:48, wishmaster wrote:
>>
>> What is your sysctl's?
>>
>> Below from my production server with 3 NIC's in bridge. I use
>> filtering only on the bridge0 interface.
>>
>> net.link.bridge.pfil_local_phys: 0
>> net.link.bridge.pfil_member: 0
>> net.link.bridge.pfil_bridge: 1
>> net.link.bridge.pfil_onlyip: 1
>>