Hello,

Confirmed on a fresh and very simple virtual environnement with 2 firewall using latest snapshot (amd64). pf.conf containt a single line "block log", nothing is logged on pflog and the other firewall on the sharing the link layer still catch carp advertisement !

Another interessting information:
- If you set pf policy to block log, reboot the system, all carp packet are properly dropped and logged in pflog0! - If you turn off pf "pfctl -d", carp is still filtered (omg !!!). Even if you set pf.conf to "pass" and turn it on again (pfctf -e) you won't be able to allow/see carp again on the system until next reboot !

Fred !

Le 29/02/2012 18:16, Marios Makassikis a icrit :
Hi all,

I am in the process of setting up a lab to test a IPv6 setup, and I'm
having some issues with filtering CARP traffic.

The configuration looks like this:

        +----| WAN/Internet |----+
        |                        |
     em0|                        |em0
     +-----+                  +-----+
     | fw1 |-xl0----------xl0-| fw2 |
     +-----+                  +-----+
     em1|                        |em1
        |                        |
        |                        |
        |                        |
     em0|                        |em0
     +-----+                  +-----+
     | br1 |-rl0----------rl0-| br2 |
     +-----+                  +-----+
        |                        |
        |                        |
     ---+-------Shared LAN-------+---

All four machines above are running OpenBSD. The firewalls (fw1 and
fw2) are running OpenBSD 5.0, while the bridges br1 and br2 are
running the latest snapshot available on /pub/OpenBSD/snapshots/
(dated 12/02/2012).


I configured two CARP devices on the firewalls:
   - carp0 for the em0 interfaces
   - carp1 for the em1 interfaces

I added the following rule in the pf.conf file, as the default policy is
to block everything

   pass quick inet proto carp

At this point, CARP seems to be working fine, but the rule isn't
actually working.
If I add the 'log' keyword, and run
   tcpdump -netvi pflog0 ip proto 112
there is no output at all.
On the other and, running the following command on fw2 gives the
expected output:
   tcpdump -netvi em1 ip proto 112

At this point I thought maybe some other rule in my ruleset is letting
CARP traffic pass, so I replaced the whole ruleset with the following:

   block log all

Sure enough, I still don't have any output on fw1, but fw2 receives
CARP packets correctly.

I should mention that originally, all machines were running -current,
which made me think a regression may have been introduced. After
reinstalling 5.0 on the firewalls and copying back the configuration
files, the issue seemed to have disappeared, as I could match CARP
packets:

rule 25/(match) [uid 0, pid 28901] pass out on em1: carp 192.168.200.253
224.0.0.18: CARPv2-advertise 36: vhid=48 advbase=1 advskew=50 demote=2
(DF) [tos 0x10] (ttl 255, id 57018, len 56, bad cksum 0!)
rule 25/(match) [uid 0, pid 28901] pass in on em1: carp 192.168.200.252
224.0.0.18: CARPv2-advertise 36: vhid=48 advbase=1 advskew=100
demote=0 (DF) (ttl 255, id 31275, len 56)
...

Additionally, I should add that all the machines are dual-stacked.
Perhaps this has to do something with the problem, although I have the
exact same issue.
For instance, 'block all' doesn't actually block, and the one time I had
PF matching the IPv4 CARP packets, it also matched the IPv6 ones:

rule 34/(match) [uid 0, pid 7854] pass out on em1:
fe80::20e:cff:fe68:aad2>  ff02::12: CARPv2-advertise 36: vhid=48
advbase=1 advskew=50 demote=0 (len 36, hlim 255)
rule 34/(match) [uid 0, pid 7854] pass in on em1:
fe80::202:b3ff:feb2:e6ce>  ff02::12: CARPv2-advertise 36: vhid=48
advbase=1 advskew=100 demote=0 (len 36, hlim 255)
...

Attempts at blocking CARP traffic on the bridge were equally
unsuccessful.

A last test prior to posting got me the following results:
The pf.conf file contained this rule at the top:
   block quick log inet proto carp
And CARP was effectively blocked. Changing the 'block' to 'pass' allowed
the packets to flow, as expected. Changing it back again to block has no
effect.

Can anyone explain this strange behaviour?

Thanks,

Marios.

Reply via email to