Hi, Reading this a bit late but something doesn't sound quite right. Just ignore me if I'm reading this wrong..
An IPSec tunnel policy defines both the local network *and* the remote network. So for a packet to be encrypted it must have both a source IP address within the local subnet and a destination IP address within the remote subnet according to the VPN policy (as seen with 'ipsecctl -sa'). The internet will also drop RFC1918 sourced packets anyway, but you don't want to leak unencrypted packets. If you want to send a packet from the local OpenBSD router itself to the remote network securely you can simply add a static route on the local OpenBSD router for the remote network to go via the local OpenBSD routers internal interface's IP address. This causes the packet generated by the local router to have its source IP set to the IP of the internal interface. Assuming this internal interface is within the local subnet defined by the VPN policy definition it will be encrypted. If I understand the suggestion the gre-tunnel idea can be useful of you want the local carp-backup firewall in a CARP pair running sasyncd to also be able to send packets itself to the remote network securely via the tunnel (which of course needs to go via the local carp-master which holds the current phase-1 trust). I don't believe sasyncd can fully syncronise all of the phase 1 and 2 keys fully yet to allow the carp-backup to send the packet itself directly without the remote resetting the trust. Andy. On Mon, 10 Feb 2014 21:48:27 -0800, Zach Leslie <xaque...@gmail.com> wrote: > On Mon, Feb 10, 2014 at 07:58:39PM +0100, Aurelien Martin wrote: >> > net.inet.icmp.rediraccept=1 # 1=Accept ICMP redirects >> >> Good to know this feature :) >> >> > Are systems behind the firewall able to route to and reach the remote >> network? >> >> Yes all is working. >> >> > we could route through the device, but packets that originated from the >> router were not able to make it through >> >> This is also my case >> >> >create a static route for the remote network to use the external >> >interface >> of the remote router as the gateway >> >> Is it the best practice to create a static route to allow packet from >> router (eg: for unbound) to reach the remote LAN ? Even with "ping" >> Redirect Host "overhead"? > > I can't say if this is the best practice, but it is one that works. > Since you have the flows in place to know how to reach the remote router > securely, the traffic should pop out the enc interface for filtering > etc. It does mean that you need to be a bit more aware of what the > traffic is and how to filter it, since now to allow the router to > communicate with a machine on the remote network, you must specify the > external IP as the source, which offends me. > > I can't confirm, but I also expect that this has some strange behavior, > or poses the potential for traffic to be unencrypted, since you are > manually specifying the routes. If the IPSec is down, will traffic > still flow? And if it does, that means you are sending traffic in the > clear across the untrusted network. Less than ideal. Something to keep > in mind, and again, I've not confirmed thats the case. This may be a > problem only be for me in my test lab because the external interfaces > were on the same network and my not be an issue when routing across the > internet. > > Another option you have, which I am not using yet, but like better, is > to build a gre or gif tunnel over the ipsec. This way as far as routes > are concerned, all traffic is private in the rfc1918 space, or whatever, > and shows up in the routing table in a neater way without routes leaving > the private address space. This means that the gre tunnel should be the > only thing coming out of the enc interface, and then the traffic is > unwrapped (un-tunneled?) on the gre interface. > > This may yet be my approach, since I may need OSPF between sites, though > I don't know how the carp will behave here. I deploy my firewalls > tomorrow morning, so its all still a work in progress. > > Let us know how of any findings.
