Nick Golder wrote: > On 2007-11-07 14:29 -0500, Steven Surdock wrote: >> Nick Golder wrote stuff: ... > Is this a PF bug?
[Shrug]. They way it _seemed_ to work (for me, when I implemented the system back on 3.8 or 3.9, YMMV) was that "route-to/reply-to" caused the packet not to hit the normal routing table (on a "pass in" statement) but go where I told it. Once a packet hit the routing table it didn't seem to use the route-to/reply-to statements (pass out...). I have seen other implementation on this list (using tagged packets). If you follow this list you'll also know that several developers cringe at the route-to/reply-to statements. I have also not seen a successful implementation of route-to/reply-to if a service originates (or proxies) traffic from the firewall (e.g. squid or ftp-proxy...), which tend to support my observations above. I would be curious to know the effect of multipath routing in this scenario, but I have not had a chance to test it. > I assume you are running OpenVPN in UDP mode? ... Yes. But I also run a second OpenVPN process in TCP mode (port 443) to get around a few (very few) places that still only allow 80/443. UDP has less overhead and "feels" faster, but I have never performed any measurements. -Steve S.
