I am trying to serve out OpenVPN (port 1194 UDP) through multiple external interfaces. It works fine for the external interface $ext_if1 which has a default route. When I try to serve port 1194 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. ext_if1="em0" ext_if2="em5"
OpenVPN is listening on all interfaces: $ netstat -p udp -a -n | grep 1194 udp 0 0 *.1194 *.* The filter rules look correct according to pfctl -sr: pass in on em0 inet proto udp from any to 10.22.33.44 port = 1194 keep state pass in on em5 reply-to (em5 10.33.22.254) inet proto udp from any to \ 10.33.22.11 port = 1194 keep state I allow all outgoing traffic on em5 and I also created a route-to rule for $ext_if2: pass out on em0 route-to (em5 10.33.22.254) inet from 10.33.22.11 \ to any flags S/SA keep state The state-policy is set to 'floating'. I can see the state table get updated with the incoming traffic on $ext_if2 and the corresponding reply traffic which is going out on $ext_if1 (which, again, has the only default route). Also, the state table is already maintaining states for port 1194 on $ext_if1. Is this the wrong application for 'reply-to'? If so, what would be the correct way to handle incoming traffic on a route-less interface? Even if the 'reply-to' rule isn't followed, shouldn't the 'route-to' rule work? -- Nick Golder
