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 <[email protected]> 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 Refs Use Mtu Prio Iface > default 172.16.94.113 UG 2 482 - 32 tun0 > default 217.0.116.247 UGS 20 203 - 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
