[Openswan Users] Openswan + quagga/ospfd routing problem

[Ralf Guenthner]

Dear list

I have a quite challenging problem pertaining to Openswan in conjunction 
with quagga/ospfd. The details are as follows:

We've successfully established a failover solution with OSPF between two 
remote locations. I'm not very good at ASCII art, so please excuse the 
wordiness of the following description.

OS=SuSe 9.3, Kernel 2.6.11.4-21.7-default

The network topology looks like this:

Router A:

eth0 192.168.254.1 -----> 192.168.254.2  (direct link, 10 MBit Ethernet)
eth1 10.42.68.5  -----> 172.16.3.20 (Cisco PIX VPN tunnel via Internet)
eth2 192.168.90.2 ---> internal
default route is: 192.168.90.1

Network behind internal Gateway is: 192.168.32.0/16

Router B:
eth0 192.168.254.2 ---> 192.168.254.1
eth1 172.16.3.20  ----> 10.42.68.5
eth2 192.168.11.1 ---> internal
default route is: 192.168.11.2

Network behind internal gateway is: 192.168.100.0/22

If the direct link goes down for some reason, we want the traffic 
from/to the internal networks to go over the Cisco tunnel automatically. 
Since our Cisco firmware doesn't support broadcast traffic yet I 
established a GRE tunnel over the CISCO VPN like this:

Router A:
ip tunnel add gre1 mode gre remote 172.16.3.20 local 10.42.68.5
ip address add 10.0.0.1 peer 10.0.0.2 brd + dev gre1
ip link set gre1 up multicast on

ospfd.conf Router A:

interface eth0
  description default connection via direct link
  ip ospf authentication message-digest
  ip ospf message-digest-key 2 md5 MYKEY
  ip ospf cost 50

interface gre1
  description failover connection
  ip ospf network point-to-point
  ip ospf authentication message-digest
  ip ospf message-digest-key 2 md5 MYKEY
  ip ospf cost 100

router ospf
ospf router-id 192.168.254.1
!
network 192.168.254.0/24 area 0
network 10.0.0.2/32 area 0
!
redistribute kernel

ospfd.conf Router B:

interface eth0
  description default connection via direct link
  ip ospf authentication message-digest
  ip ospf message-digest-key 2 md5 MYKEY
  ip ospf cost 50

interface gre1
  description failover connection
  ip ospf network point-to-point
  ip ospf authentication message-digest
  ip ospf message-digest-key 2 md5 MYKEY
  ip ospf cost 100

router ospf
ospf router-id 192.168.254.2
!
network 192.168.254.0/24 area 0
network 10.0.0.1/32 area 0
!
redistribute kernel

Everything works as it should! When I down the eth0 interface on one of 
the routers, the routes are changed to the Cisco VPN connection via the 
GRE tunnel addresses (10.0.0.1 and 10.0.0.2) and back to 192.168.254.1, 
when the NIC comes back up.

Now Openswan comes into play:
We want to encrypt the traffic over the default connection (which is a 
dedicated Ethernet link, not an Internet connection) with Openswan. So I 
did this in the ipsec.conf:

interfaces="ipsec0=eth0"

Router A:
conn torouterB
         left=192.168.254.1
         leftsubnet=192.168.32.0/24
         leftnexthop=10.42.68.8
         right=192.168.254.2
         rightsubnet=192.168.100.0/22
         rightnexthop=172.16.3.4
         rightcert=xxCert.pem
         rightid="xxxxx"
         auto=start

Router B:
conn torouterA
         left=192.168.254.2
         leftsubnet=192.168.100.0/22
         leftnexthop=172.16.3.4
         right=192.168.254.1
         rightsubnet=192.168.32.0/16
         rightnexthop=10.42.68.8
         rightcert=xxxxCert.pem
         rightid="xxxxx"
         auto=start

IPSEC in itself works, too. OSPF broadcasts are sent via the primary 
link unencrypted, only the "real" payload packets originating in one of 
the networks behind the Linux routers are sent into the tunnel.

But maybe you've already spotted what my problem is now: Openswan on 
Router A already sets a route to the remote network 192.168.100.0/22, 
but the same network is also advertised by Router B via OSPF. Vice versa 
on Router B for the network 192.168.32.0/24.

If I disable eth0 on Router A, and Openswan is still running on both 
routers the packets to the remote network will still get sent into the 
IPSEC tunnel, even though the interface on Router A to which the ISPEC 
tunnel is bound has gone down. So no packets are sent over the 
replacement VPN link. At least that's my theory what happens...

If I do an "ipsec setup stop" on Router A AND Router B, the failover 
immediately takes place. Also, if eth0 is back up and I do an "ipsec 
setup start" on both routers it switches back to the primary link.

How can I solve this situation? As far as I can tell, I'd need a way to 
have ipsec stop itself automatically on both routers and then restart as 
soon as the link returns.

Thanks in advance for any advice

Regards
Ralf G.