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. -- Zach
