Re: Possible PF bug with block and reply-to

[Jason Meltzer]

Hey Michael,

I wrote a response, see below, but for future reference your question
should have been directed at misc@. The tech@ list is for discussions
related to development. Please look over http://openbsd.org/mail.html
before posting.

On Thu, Apr 7, 2011 at 15:20, Michael Lechtermann
mich...@lechtermann.net wrote:
 Hello,

 sorry for the long text, but I try to be thorough with the description.

 I have a router which connects to another machine using a Layer 2 VPN.
 When that connection is active, a new default route with higher
 (actually its numerically lower) priority is added, to overwrite the old
 one.

 Destination   Gateway  Flags   RefsUse   Mtu  Prio Iface
 default   172.16.94.113UG 2482 -32 tun0
 default   217.0.116.247UGS   20203 -48 pppoe0


 For incoming connections on pppoe0 I am using reply-to, so the packets
 go back out where they came in. That works really good.

 Now, in the pf.conf I am setting set block-policy return, just to be
 nice and to allow for easier debugging.

 The problem here is, that with just having a block log at the
 beginning of the ruleset, those ICMP and TCP resets are being sent out
 using tun0 instead of pppoe0.

 I didn't see that at first but I guess it is to be expected.

 Now I added a block in log on $ext_if inet reply-to ( ... ) rule, but
 it seems, that the reply-to part is getting ignored here. The resets
 packets still go out using the tun0 interface.

 Unfortunately it also isn't possible to use reply-to with match rules.

The immediate problem here is that reply-to is a routing decision
and will therefore only will work for packets that are actually
routed... implicitly this means that state has been created for the
connection but blocked packets do not create state: reply-to
will not work for 'block' rules.

From the pf.conf man page (emphasis mine):

reply-to
   The reply-to option is similar to route-to, but routes packets
that
   pass in the opposite direction (replies) to the specified
   interface.  *** Opposite direction is only defined in the
context of a
   state entry, and reply-to is useful only in rules that create
   state***.  It can be used on systems with multiple external
   connections to route all outgoing packets of a connection through
   the interface the incoming connection arrived through (symmetric
   routing enforcement).

Another issue here is the nature of sppp/pppoe: they aren't interfaces
that send packets but are abstractions for running a PPP stack on an
interface and this has implications where using pf is concerned. It is
actually important conceptually, as you'll find similar behaviour if
you try to get clever with using pf on other pseudo-interfaces, such
as carp(4), and happen to make incorrect assumptions about the nature
of the interface.

Cheers,

-Jason

Possible PF bug with block and reply-to

[Michael Lechtermann]

Hello,

sorry for the long text, but I try to be thorough with the description.

I have a router which connects to another machine using a Layer 2 VPN.
When that connection is active, a new default route with higher
(actually its numerically lower) priority is added, to overwrite the old
one.

Destination   Gateway  Flags   RefsUse   Mtu  Prio Iface
default   172.16.94.113UG 2482 -32 tun0
default   217.0.116.247UGS   20203 -48 pppoe0


For incoming connections on pppoe0 I am using reply-to, so the packets
go back out where they came in. That works really good.

Now, in the pf.conf I am setting set block-policy return, just to be
nice and to allow for easier debugging.

The problem here is, that with just having a block log at the
beginning of the ruleset, those ICMP and TCP resets are being sent out
using tun0 instead of pppoe0.

I didn't see that at first but I guess it is to be expected.

Now I added a block in log on $ext_if inet reply-to ( ... ) rule, but
it seems, that the reply-to part is getting ignored here. The resets
packets still go out using the tun0 interface.

Unfortunately it also isn't possible to use reply-to with match rules.

Sadly I just have some very basic C skills, meaning that all the PF
stuff is way over my head. I hope that someone help me here. ;-)

If you want to see my /etc/pf.conf, I'll send it off list.

Regards,
Michael Lechtermann


# dmesg
OpenBSD 4.9 (GENERIC) #671: Wed Mar  2 07:09:00 MST 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD
586-class) 499 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
real mem  = 268009472 (255MB)
avail mem = 253493248 (241MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/10/07, BIOS32 rev. 0 @ 0xfceb2
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x31
glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10,
address 00:0d:b9:12:73:54
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 10 function 0 VIA VT6105M RhineIII rev 0x96: irq 11,
address 00:0d:b9:12:73:55
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr2 at pci0 dev 11 function 0 VIA VT6105M RhineIII rev 0x96: irq 12,
address 00:0d:b9:12:73:56
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
glxpcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03: rev 3,
32-bit 3579545Hz timer, watchdog, gpio
gpio0 at glxpcib0: 32 pins
pciide0 at pci0 dev 15 function 2 AMD CS5536 IDE rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: TRANSCEND
wd0: 1-sector PIO, LBA, 971MB, 1989792 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 AMD CS5536 USB rev 0x02: irq 15,
version 1.0, legacy support
ehci0 at pci0 dev 15 function 5 AMD CS5536 USB rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1
biomask e3ef netmask ffef ttymask 
mtrr: K6-family MTRR support (2 registers)
nvram: invalid checksum
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
clock: unknown CMOS layout
gpioow0 at gpio0: DATA[4] open-drain pull-up
onewire0 at gpioow0