More IPSEC routes for OSPF

[Iain Buchanan]

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 <iainbuc at gmail.com> wrote:

> Thanks Ruben, I'll give the script option a go.
>
> Iain
>
>
> On 11 November 2013 14:19, Ruben Laban <r.laban+lists at 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20131114/d9e323c1/attachment-0001.html>