Routing for VPN network

Ask Bjørn Hansen ask at develooper.com
Wed Apr 6 03:15:29 CEST 2011


On Apr 3, 2011, at 18:35, Ondrej Zajicek wrote:

>> Would it make sense to use OSPF for this instead?  My only experience
>> with OSPF is setting it up between routers in one site so they know how
>> to get to the 'next hop' of routes coming in and shared via BGP/IBGP.
> 
> I think OSPF should work just right for such setting.

Thank you!

I got it to work in a basic test setup.  When I "upgraded" OpenVPN to use certificates and server mode (so the servers can use a relatively simple configuration) I can no longer make it work.

Maybe the hack that OpenVPN uses in this mode is incompatible with bird.  I'll explain to have you verify or maybe suggest a work-around.

I have OpenVPN use a 'pool' of addresses (10.221.0.0/24).

What it does is setup tun0 as a PtP link (.1 being itself and .2 being the 'remote') and then add a route for 10.221.0.0/24 going to 10.221.0.2.   Then OpenVPN does the routing to the actual remote end-points (.4, .5, ...) internally.

From the manual page I gathered that I need to use 'point to multipoint' mode and specify the neighbors manually.   I tried that; but even so then the .1 IP keeps sending Hello packets to the .2 IP (the other end of the PtP link that goes to the openvpn process).   The remote bird is configured to use .1 as a neighbor and does so dutifully; but according to tcpdump I only get "hello" packets going back and forth.

I'm including the ospf section of my bird configuration.  This is the "server side".  The client side is the same except the neighbor is .1.  I'm also including 'show interfaces' that shows the mismatched perception of the tunnel IPs.

 - ask


protocol ospf ntp {
        debug all;
        rfc1583compat yes;
        import all;
        export filter {
                if (source = RTS_STATIC) then accept;
                else reject;
        };
        area 0 {
                interface "tun0" {
                        cost 20;
                        type ptmp;
                        hello 5; retransmit 2; wait 10; dead 60;
                        authentication none;
                        neighbors { 10.221.0.4; };
                };
        };
}

[server]# birdc show interfaces
BIRD 1.3.0 ready.
lo up (index=1)
	MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436
	127.0.0.1/8 (Primary, scope host)
eth0 up (index=2)
	MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500
	207.171.3.3/29 (Primary, scope univ)
	207.171.3.6/29 (Secondary, scope univ)
eth1 up (index=3)
	MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500
	10.220.0.12/24 (Primary, scope site)
sit0 DOWN (index=4)
	MultiAccess AdminDown LinkDown MTU=1480
tun0 up (index=19)
	PtP Multicast AdminUp LinkUp MTU=1500
	10.221.0.1/32 (Primary, opposite 10.221.0.2, scope site)


[client]# birdc show interfaces
BIRD 1.3.0 ready.
lo up (index=1)
	MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436
	127.0.0.1/8 (Primary, scope host)
eth0 up (index=2)
	MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500
	64.142.113.2/27 (Primary, scope univ)
sit0 DOWN (index=3)
	MultiAccess AdminDown LinkDown MTU=1480
dummy0 DOWN (index=4)
	MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500
dummy1 up (index=5)
	MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500
	10.220.1.1/24 (Primary, scope site)
dummy2 DOWN (index=6)
	MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500
tun0 up (index=16)
	PtP Multicast AdminUp LinkUp MTU=1500
	10.221.0.4/32 (Primary, opposite 10.221.0.1, scope site)




More information about the Bird-users mailing list