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.localRelevant 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.confAfter some time, it's wise to check if flows are up:
# ipsecctl -s aIf 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 bridge0At 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 reloadIt 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 2d23h33mRegards,
Maxim
Thanks Maxim for the hints and great descriptions!
(Comments are closed)
By Stefan Sperling (stsp) stsp@openbsd.org on http://stsp.name
By Uwe Werler (155.56.68.216) uwe@werler.eu on
Comments
By Nug (139.228.33.221) on
Comments
By Uwe Werler (155.56.68.216) uwe@werler.eu on
No, tun.
By hgk (179.154.27.91) on
A quick and fast ideias in mind ... GRE (mobile IP) / mGRE (DMVPN) ??
What about L2TP+IPSec ?
Comments
By Uwe Werler (155.56.68.216) uwe@werler.eu on
>
> 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).
By sthen (2001:8b0:648e:cc01:f2de:f1ff:fef9:a752) on http://www.britishpathe.com/video/blazing-barrels/
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).
Comments
By sthen (2001:8b0:648e:cc01:f2de:f1ff:fef9:a752) on http://www.britishpathe.com/video/blazing-barrels/
Comments
By sthen (2001:8b0:648e:cc01:230:48ff:fe58:8640) on
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").
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?