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).
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". Do I need to specify my local IPSEC policies in a different format, or am I missing something in the configuration? log syslog all; debug protocols all; protocol kernel { learn; persist; scan time 10; import all; export none; kernel table 1; # This is my new table populated with IPSEC policies } protocol device { scan time 10; } protocol ospf myOSPF { import all; export all; area 0 { interface "tunOtherRouter" { # This is the GRE tunnel cost 5; type ptp; hello 5; retransmit 2; wait 10; dead 20; }; }; } On 12 November 2013 21:41, Iain Buchanan <iain...@gmail.com> wrote: > Thanks Ruben, I'll give the script option a go. > > Iain > > > On 11 November 2013 14:19, Ruben Laban <r.laban+li...@ism.nl> wrote: > >> Hi, >> >> >> On 10-11-2013 16:35, Iain Buchanan wrote: >> >>> I’m in pretty much the same position. I’ve tried Ondrej Zajicek’s >>> suggestion of using transport mode IPSEC links, but this doesn’t seem to >>> create visible routes (I’m using the netkey stack, which may be the >>> issue). At the moment I’ve got GRE tunnels working on top of the IPSEC >>> links, and if I enable debugging mode I can see instances of Bird >>> communicating with one another over them (but not sending any of the >>> OpenSWAN link information). >>> >> >> 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: >> >> * Have a script parse the IPsec policies, or >> * Use the KLIPS stack instead of NETKEY, which gives you routes you can >> insert into OSPF nicely (this is what I do). >> >> Regards, >> Ruben >> >> >> >