OK, so I finally got Strongswan with a GRE over IPSec tunnel and OSPF (BIRD) running on Centos 6

Two remote sites are connected to the main site via Metro-Ethernet. In case of the Metro failing, the idea is to establish backup connectivity over the Internet via secure VPN tunnels. That poses a few problems: IPSec alone doesn’t play well with routing protocols (OSPF in my case), which is why we need GRE over IPSec. I chose “Strongswan” for IPSec on Centos 6 – the Centos 6 was already in place and I didn’t want to first update everything to Centos 7.

Note, Centos 6 uses iproute2, which does not support VTI interfaces ๐Ÿ™

A “few” caveats that the usual how-to docs don’t quite seem to address:

  • make sure your ipsec.conf is in “transport” mode, not “tunnel”, or you’re in a world of pain nailing your GRE on it. Mind you, GRE will still come up if you do things wrong, but it won’t be encrypted! And of course the only way to see that is via packet capture on/past the switch port (yay switch port mirrors!)
  • The above will also help solve the issue of “left/rightsubnet” being “0.0.0.0/0” in both tunnels – you don’t need to specify left/rightsubnet in the conn section of ipsec.conf
    (Two “tunnel” tunnels with left/rightsubnet 0.0.0.0/0 easily results in that you can only ping across the tunnel that came up last. And I couldn’t get the mark/key options of ‘tunnel’/’ipsec.conf’ to work right)
  • Once your tunnel is up and you can ping across it, OSPF might still not come up at all. I saw “OSPF HELLO” packets leave, but they never arrived at the other side. Wireshark to the rescue (via mirrored switch port) and lo and behold – the TTL is “1”, which is a tad small. Bring up your tunnel interface with “ip tunnel add… ttl=64
  • While all this might be “obvious” to people who’ve “been there” before, it wasn’t obvious to me and my google-fu totally failed for quite a while. I hope this helps others (and future-me).