On 2007-11-06 09:00 +0100, Jeremie Le Hen wrote: > Hi Nick, > > On Sun, Nov 04, 2007 at 05:45:54PM -0700, Nick Golder wrote: > > I am trying to serve out OpenVPN (port 1194) through multiple external > > interfaces. It works fine for the external interface $ext_if1 which has > > a default route. When I try to serve it out on $ext_if2 using > > 'reply-to', tcpdump shows the packets arrive in on $ext_if2 but > > the replies are still going out on $ext_if1. OpenVPN is listening on > > all interfaces: > > $ netstat -p udp -a -n | grep 1194 > > udp 0 0 *.1194 *.* > > > > The filter looks correct (with obfuscated ips - but those are correct): > > $ sudo pfctl -sr | grep 1194 > > pass in on em0 inet proto udp from any to 11.22.33.44 port = 1194 keep state > > pass in on em5 reply-to (em5 44.33.22.254) inet proto udp from any to \ > > 44.33.22.11 port = 1194 keep state > > > > For good measure, I also created a route-to rule for $ext_if2 (which > > should never be used since all this interface will do is serve port 1194): > > pass out on em0 route-to (em5 44.33.22.254) inet from 44.33.22.11 \ > > to any flags S/SA keep state > > > > The state-policy is set as floating. When I load the rules, I used > > pfctl -f /etc/pf.conf - so I didn't flush my state tables so states > > persist that are bound for port 1194 on $ext_if1. Is this my problem? > > > > Any ideas as to why my reply-to filter rule isn't working? > > Reply-to's are associated with state entries which, in turn, are > associated to interface. At least this is what I've understood from my > own experience: indeed you have to set a state on both the incoming and > outgoing interface to let a packet/stream go through. Moreover, > reply-to's are by definition applied on the reverse path, on the same > interface as the rule that set it. Considering that pf can only change > a packet route *before* it has been routed actually routed by the kernel > (correct me if I'm wrong), this means you have to set the reply-yo rule > on the output path of the forward packet, so it will be triggered in the > input path of the reverse packet.
I can see the state table get updated - the incoming state gets created as well as a corresponding outgoing state except the outgoing is create for the interface with the default route. If I change the 'pass in on' rule and remove the 'reply-to', it behaves exactly the same. So it seems the 'reply-to' is skipped. I don't follow what why I would want my 'reply-to' on the output path. Reading the docs make it sound like 'reply-to' is used for incoming incoming rules and 'route-to' is used for outgoing. An example would help. > > FWIW, I'm tagging packets on the input path to apply reply-to on the > output path. I did try tagging incoming packets and using the 'route-to' on tagged packets but that didn't seem to help either. And maybe I don't understand 'reply-to' but I can't see how it works on outbound packets on an external interface. -- Nick Golder
