OpenBSD Journal

OSPF over IPsec

Contributed by tbert on from the shortest-path-measuring-contest dept.

Maxim Bourmistrov (maxim<at>unixconn<dot>com) wrote in to tell us about his Open Shortest Path First (OSPF) over IP Security Protocol (IPsec).

While looking for a solution for OSPF over IPsec, I found a lot of articles about how to do this over gre(4). The other possibility is to use gif(4) instead. I've tested both and was not quite happy with results. The gre(4) approach had some generic issues and the gif(4) approach had problems with multicast at times. Yet, I need to have "OSPF over IPsec" up and running.

Luckily, I remembered Theos' presentation about vether(4). While Theos' presentation was mostly written from developer perspective and not from administrators point of view, he left some clues about how this can be done.

The info below is how I do "OSPF over IPsec", or should I say "OSPF on top on vether on top of gif on top of IPsec".

All information needed for this setup can found in manual pages, especially in gif(4). OpenBSD 5.3 is used on both ends. Note, that steps below are only for one of two nodes. For the second, remote one, it should be straight forward after the first one.

1. Configuring IPsec

I'll use isakmpd(8) for several unrelated reasons, but it should be fine to replace it with iked(8).

Enable isakmpd(8) to start on boot and load of rules from ipsec.conf(5):

# echo 'isakmpd_flags="-K" ' >> /etc/rc.conf.local

Relevant ipsec.conf(5):

local_ext_ip="1.2.3.4"
remote_ext_ip="4.3.2.1"

ike active esp transport from $local_ext_ip to $remote_ext_ip peer $remote_ext_ip \
        main auth "hmac-md5" enc "aes-128" group modp1024 \
        quick auth "hmac-md5" enc "aes" group modp1024 \
        srcid $local_ext_ip \
        psk "<pre-shared key goes here>"

Now it is time to start isakpmd(8).

# /etc/rc.d/isakmpd start
# ipsecctl -f /etc/ipsec.conf

After some time, it's wise to check if flows are up:

# ipsecctl -s a

If they are, you are ready to proceed to the next step below.

2. Setting up bridge(4) with vether(4) and gif(4)

# cat /etc/hostname.bridge0:
add gif0 add vether0
up link2

# cat /etc/hostname.vether0
inet 10.10.10.1 255.255.255.252 NONE -inet6 mtu 1500

# cat /etc/hostname.gif0
tunnel 1.2.3.4 4.3.2.1 -inet6 mtu 1500

# ifconfig bridge0 create
# ifconfig vether0 create
# ifconfig gif0 create

# sh /etc/netstart vether0
# sh /etc/netstart gif0
# sh /etc/netstart bridge0

At this point you should be able to ping 10.10.10.2, i.e. the remote end of this tunnel.

3. Configuring ospfd(8)

The complete configuration of ospfd(8) is out of the scope here, but regarding this setup, ospfd(8) should listen on vether0:

interface vether0 { metric 10 }

Reload ospfd

# ospfctl reload

It is good practice to start with disabled pf(4) filtering on mentioned above interfaces:

set skip on { gif bridge vether }

and do filtering on enc(4):

pass on enc0 keep state (if-bound)

(Editor's Note: If you're just debugging, using 'set skip on enc0' would be more efficient than 'pass on enc0'. Also if you do decide to filter on enc0, you will probably want to restrict enc0 to 'protocol ipencap' as shown in the enc(4) manual).

Here is how this looks like then all is up and running:

# ospfctl show neighbor
ID              Pri State        DeadTime Address         Iface     Uptime
0.0.2.7         1   FULL/DR      00:00:30 10.11.11.11     vic2      2d23h33m
0.0.1.2         1   FULL/DR      00:00:34 30.0.2.2        vether1   2d23h33m
0.0.1.1         1   FULL/DR      00:00:35 30.0.1.2        vether0   2d23h33m

Regards,
Maxim

Thanks Maxim for the hints and great descriptions!

(Comments are closed)


  1. By Stefan Sperling (stsp) stsp@openbsd.org on http://stsp.name

    It would be great to have a similar guide for ospf6d. OSPF for IPv6 lacks built-in authentication of OSPF packets. RFC 5340 says IPsec should be used instead (see also RFC 4552). Apart from a warning in the BUGS section of the osf6d man page we lack documentation describing how to configure this properly. I tried to write documentation for this once but gave up because I lack the necessary IPsec skills.

  2. By Uwe Werler () uwe@werler.eu on

    It's only usefull in 1:1 scenarios. If You want to have a kind of star topology this doesn't work 'cause gif/gre only work in 1:1 and not 1:n mode. That's why I used OSPF via an OpenVPN tunnel.

    1. By Nug () on

      OpenVPN using tap?

      1. By Uwe Werler () uwe@werler.eu on

        > OpenVPN using tap?

        No, tun.

    2. By hgk () on

      > It's only usefull in 1:1 scenarios. If You want to have a kind of star topology this doesn't work 'cause gif/gre only work in 1:1 and not 1:n mode. That's why I used OSPF via an OpenVPN tunnel.

      A quick and fast ideias in mind ... GRE (mobile IP) / mGRE (DMVPN) ??
      What about L2TP+IPSec ?

      1. By Uwe Werler () uwe@werler.eu on

        > > It's only usefull in 1:1 scenarios. If You want to have a kind of star topology this doesn't work 'cause gif/gre only work in 1:1 and not 1:n mode. That's why I used OSPF via an OpenVPN tunnel.
        >
        > A quick and fast ideias in mind ... GRE (mobile IP) / mGRE (DMVPN) ??
        > What about L2TP+IPSec ?

        Unfortunately OpenBSD has no mGRE :(

        At the time I've created this setup there was no npppd, that's why we used OpenVPN (and yes, now there is pipex).

  3. By sthen () on http://www.britishpathe.com/video/blazing-barrels/

    Could you expand on the problem with multicast on gif? That shouldn't affect ospf itself (it uses multicast on ethernet-like interfaces, but a gif(4) would be point-to-point).

    People reading this might also be interested in http://bodgitandscarper.co.uk/openbsd/openbsd-ipsec-and-rfc-3884/, it's quite a clean solution (though as things stand, it is restricted to manual keying).

      1. By sthen () on

        Since I had a mail asking about this, this is different to just doing standard ospf+gif+ipsec (which *does* work with standard isakmpd IKE), I wrote a reply to the mail, but I think it makes sense to copy it here too:

        This method means that the ipsec tunnel encapsulation is done directly by the gif(4) interface (via a standard route table entry), there's no flow entry so ipsec is just used to encrypt things, it doesn't use ipsec's tunnel encapsulation code at all.

        The device at the other side can use either method, it can either be setup the same way with a gif interface, *or* it can have a "standard" IPsec configuration (i.e. just using isakmpd, or using a cheap router that only supports ipsec and not gif).

        This works because gif(4)'s tunnel encapsulation is exactly the same as used by IPsec. This is particularly useful for vpn concentrators; you can use it on the central side to allow you to redistribute vpn routes using a dynamic routing protocol, but the "client"/remote side doesn't even need to know that you are doing this, they can just configure a standard IPsec connection, no separate gif interface needed on their side.

        Another advantage is if you're using the tunnel as a fallback route to a standard connection (e.g. as a backup to an ethernet-presented leased line), you can then just use a lower-priority route table entry, and as long as you have link state detection on the standard connection, you don't even need a routing protocol. (Without using this method the flow would 'steal' packets so you would need to bring up the tunnel on-demand when the main link fails).

        rfc3884 section 2.3 / 2.4 has more about the problems this solves, and you'll find some Cisco/Juniper documentation (usually referring to a "route-based VPN" instead of "policy-based VPN").

  4. By Dan Shechter (danshtr) danshtr@gmail.com on http://dans-net.com


    Never used IPSec on OBSD, but what are the "generic issues" with GRE?

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]