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.

FWIW, I'm tagging packets on the input path to apply reply-to on the
output path.

If I'm right here, this certainly deserves a small (and clearer than
my) note in the manual page.

Regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >

Reply via email to