<div dir="ltr">Thanks Ruben, I'll give the script option a go.<div><br></div><div>Iain</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 11 November 2013 14:19, Ruben Laban <span dir="ltr"><<a href="mailto:r.laban+lists@ism.nl" target="_blank">r.laban+lists@ism.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<div class="im"><br>
<br>
On 10-11-2013 16:35, Iain Buchanan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I’m in pretty much the same position.  I’ve tried Ondrej Zajicek’s<br>
suggestion of using transport mode IPSEC links, but this doesn’t seem to<br>
create visible routes (I’m using the netkey stack, which may be the<br>
issue).  At the moment I’ve got GRE tunnels working on top of the IPSEC<br>
links, and if I enable debugging mode I can see instances of Bird<br>
communicating with one another over them (but not sending any of the<br>
OpenSWAN link information).<br>
</blockquote>
<br></div>
The idea here is to have IPsec protected GRE tunnels over which one can talk OSPF. There wouldn't be any IPsec routes to (re)distribute in that case (as there's only transport ones). If you have other IPsec "routes" (policies in fact) that you want to insert into OSPF, then you'll need one of two alternatives indeed:<br>

<br>
* Have a script parse the IPsec policies, or<br>
* Use the KLIPS stack instead of NETKEY, which gives you routes you can insert into OSPF nicely (this is what I do).<br>
<br>
Regards,<br>
Ruben<br>
<br>
<br>
</blockquote></div><br></div>