<div dir="ltr">I've got my script going, but I can't get the resulting routes into Bird.  I add the routes to a new kernel table which I point a "protocol kernel" block at (see below).  The routes I'm adding don't go via a particular interface as OpenSWAN doesn't create any interfaces - I'm just putting them in as "target network" via "local ip address" (this might be one problem - I've tried both the internal IP and the GRE tunnel endpoint).<div>
<br></div><div>When I start Bird up I receive warnings about my new route with a strange next-hop address.  It then seems to completely ignore the route as "birdc" produces no output when I do a "show route".</div>
<div><br></div><div>Do I need to specify my local IPSEC policies in a different format, or am I missing something in the configuration?</div><div><br></div><div><div>log syslog all;</div><div>debug protocols all;</div><div>
<br></div><div>protocol kernel {</div><div>        learn;                  </div><div>        persist;                </div><div>        scan time 10;           </div><div>        import all;</div><div>        export none;</div>
<div>        kernel table 1;         # This is my new table populated with IPSEC policies</div><div>}</div><div><br></div><div>protocol device {</div><div>        scan time 10;           </div><div>}</div><div><br></div><div>
protocol ospf myOSPF {</div><div>        import all;</div><div>        export all;</div><div>        area 0 {</div><div>                interface "tunOtherRouter" { # This is the GRE tunnel</div><div>                        cost 5;</div>
<div>                        type ptp;</div><div>                        hello 5; retransmit 2; wait 10; dead 20;</div><div>                };</div><div>        };</div><div>}</div></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 12 November 2013 21:41, Iain Buchanan <span dir="ltr"><<a href="mailto:iainbuc@gmail.com" target="_blank">iainbuc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Thanks Ruben, I'll give the script option a go.<span class="HOEnZb"><font color="#888888"><div><br></div><div>Iain</div></font></span></div><div class="HOEnZb"><div class="h5"><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><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>
</div></div></blockquote></div><br></div>