Unable to fetch route from tunnel device
I'm trying to set up an OpenVPN server that routes for multiple sites and I'm having a bit of trouble getting Bird to add the routes that go through the tun0 device. I've configured Bird to import routes from both the OS and tun0, but filter out any routes that don't go through the tun0 IP (I only want to advertise routes that go through my OpenVPN tunnel). I'm running Bird 1.3.6. On startup, I receive messages like these:
KRT: Received route 172.24.1.16/28 with strange next-hop 172.16.254.1 Netlink: File exists Netlink: File exists OSPF: Socket error: Operation not permitted
This appears to be coming from this section of code: sysdep/linux/netlink/netlink.c: 846 if (!ng || (ng->scope == SCOPE_HOST)) { log(L_ERR "KRT: Received route %I/%d with strange next-hop %I", net->n.prefix, net->n.pxlen, ra.gw); return; } My network setup is as follows: Local IP of tun0 on OpenVPN server: 172.16.254.1/24 IP of tun0 on remote server: 172.24.1.28/28 Routes (from ip route) on OpenVPN server: 172.16.254.1 dev tun0 proto bird 172.24.1.0/28 via 172.16.254.1 dev tun0 172.24.1.16/28 via 172.16.254.1 dev tun0 Routes (from ip route) on OpenVPN client: 172.16.0.0/24 via 172.24.1.28 dev tun0 Bird config: log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; filter no_local prefix set local_nets; ip tun0; { local_nets = [ 172.16.0.0/16+ , 192.168.0.0/16+ , 10.0.0.0/8+ ]; tun0 = 172.16.254.1; printn "gw: ", gw; if gw = tun0 then accept "accept: gw is ",gw; reject "reject: gw is ", gw; } protocol kernel { learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 10; # Scan kernel routing table every 20 seconds device routes on; # this is on so we can accept routes with local nexthop import filter no_local; # don't import "local" networks import none; # Default is import all export all; # Default is export none } protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol static { } protocol direct { interface "tun0"; } protocol ospf MFOSPF { export all; area 172.16.0.0 { interface "eth4" { type broadcast; authentication none; neighbors { 10.19.7.11; }; }; interface "tun0" { type ptmp; authentication none; }; }; } Any ideas about what I'm doing wrong here? The network configuration (aside from Bird) works as I can ping from another IP, 172.16.1.11, through the OpenVPN server and out to 172.24.1.28. Is there a way to get Bird to advertise a route via OSPF that goes through a local IP (for a tun device) that is not on the same subnet as the remote network? Thanks much! --dlloyd
On Tue, Feb 14, 2012 at 11:57:07AM -0600, Dave Lloyd wrote:
I'm trying to set up an OpenVPN server that routes for multiple sites and I'm having a bit of trouble getting Bird to add the routes that go through the tun0 device. I've configured Bird to import routes from both the OS and tun0, but filter out any routes that don't go through the tun0 IP (I only want to advertise routes that go through my OpenVPN tunnel). I'm running Bird 1.3.6. On startup, I receive messages like these: ... My network setup is as follows: Local IP of tun0 on OpenVPN server: [3]172.16.254.1/24 IP of tun0 on remote server: [4]172.24.1.28/28
Routes (from ip route) on OpenVPN server: 172.16.254.1 dev tun0 proto bird [5]172.24.1.0/28 via 172.16.254.1 dev tun0 [6]172.24.1.16/28 via 172.16.254.1 dev tun0
Routes (from ip route) on OpenVPN client: [7]172.16.0.0/24 via 172.24.1.28 dev tun0
This is strange, shouldn't that be reversed (via 172.24.1.28 on server with IP 172.16.254.1 and vice versa)? This is the problem, BIRD does not accept routes with local IP as a gateway. If the gw is not relevant (for PTP VPN links), it is better to not have any gw (like in 'ip route add 172.24.1.0/28 dev tun0'). OpenVPN seems to be a bit problematic in general, see this [*] thread for more comments. [*] http://permalink.gmane.org/gmane.network.bird.user/1131 -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Dave Lloyd -
Ondrej Zajicek