On 2011-04-07, Andrew Klettke <aklet...@opticfusion.net> wrote: > We have a working IPSec VPN between two 4.8 endpoints. One of them is at > a remote location, and the other at the main office. The remote location > has its own external, routable IP (to establish the VPN), and an > internal subnet behind it. The main office has its own external IP, > though which it is NATing its own internal subnet. > > Basically, I want to force all internet traffic from the remote, > internal subnet through the main office's internal gateway so it can NAT > out from there. > > I've been attempting to accomplish this with "route-to" and "reply-to" > rules on the remote box, but have had no luck. I know IPSec keeps its > own routing table, is this interfering? Is this possible to do with PF?
OpenBSD's IPsec implementation uses flows which must strictly match the traffic's source/destination(/port/protocol) in order for it to be handled by IPsec (the "first approach" as described in rfc3884 2.3; see the paragraphs at the end of that section). So if you want the traffic to be directly handled by IPsec, the flows you configure must match all internet traffic, i.e. they must be between the remote subnet and 0.0.0.0/0. (You will have additional considerations due to the natting if the VPN endpoint is also the router for internet traffic). The alternative is to have IPsec protect just a gif(4) or gre(4) tunnel between the VPN endpoints, and use route table entries to pass internet traffic over that tunnel. This is easier to grasp as the usual PF/routing operations work with it. For this to work you'll need OpenBSD or an OS with a compatible tunnel device (e.g. gif or gre) at both ends and I think you probably also need static IP addresses at both ends. I strongly recommend testing on a non-production network especially if you will be attempting to use 0.0.0.0/0 flows. Get it wrong and you'll send *all* traffic from the main office's VPN endpoint to the remote location. (this is amusing, but not while it's happening :-)
