http://www.pro-bono-publico.de/openbsd/ipsec/

Quite a lot has changed since I wrote this page a couple of years ago, and most of the information found here is of merely anecdotical value.

OpenBSD IPSEC information

This page gives some hints for IPSEC configuration on OpenBSD.


OpenBSD and Checkpoint FW-1 4.1

Here's the set-up I've used to establish an IPSEC tunnel from OpenBSD (3.1) to Checkpoint Firewall-1 (4.1) in a SecuRemote-like way. However, due to lack of standards and documentation this only works with pre-shared keys. I didn't get the PKI approach to work, but I guess I'm in good company here.

The actual configuration is pretty trivial. Basically, all you need are suitable isakmpd.policy and isakmpd.conf files. Obviously, you'll have to change yourPassword, yourUsername and the bogus IP addresses to match your specific set-up:

/etc/isakmpd/isakmpd.policy

Authorizer: "POLICY"
Licensees: "passphrase:yourPassword"
Conditions: app_domain == "IPsec policy" && esp_present == "yes" -> "true";

/etc/isakmpd/isakmpd.conf

[General]
Default-phase-1-ID=     my-ID

[Phase 1]
245.123.3.254=          ISAKMP-remote
 
[Phase 2]
Connections=            IPSec-remote
 
[ISAKMP-remote]
Phase=                  1
Transport=              udp
Address=                245.123.3.254
Configuration=          Default-main-mode
ID=                     my-ID
Authentication=         yourPassword

[my-ID]
ID-type=                USER_FQDN
Name=                   yourUsername

[IPSec-remote]
Phase=                  2
ISAKMP-peer=            ISAKMP-remote
Configuration=          Default-quick-mode
Local-ID=               Net-local
Remote-ID=              Net-remote
 
[Net-local]
ID-type=                IPV4_ADDR_SUBNET
Network=                235.12.3.19
Netmask=                255.255.255.255
 
[Net-remote]
ID-type=                IPV4_ADDR_SUBNET
Network=                244.3.0.0
Netmask=                255.255.0.0
 
[Default-main-mode]
DOI=                    IPSEC
EXCHANGE_TYPE=          AGGRESSIVE
Transforms=             3DES-SHA

[Default-quick-mode]
DOI=                    IPSEC
EXCHANGE_TYPE=          QUICK_MODE
Suites=                 QM-ESP-3DES-SHA-SUITE

OpenBSD and Nortel Contivity

The very same set-up as above may be used to establish an IPSEC tunnel from OpenBSD (3.3) to a Nortel Contivity (software revision 4.7, connection configured as a user tunnel). Just make sure that your Contivity profile configuration meets the following characteristics:

Group profile:

User profile: I didn't mention obvious stuff like you'll need to enable non-Contivity clients, and you may very well use different encryption suites ...

OpenBSD isakmpd RoadWarrior patch

If you're running isakmpd on a system with a dynamically assigned IP address (quite popular for dial-up and ADSL accounts), you may end up updating your IP address in /etc/isakmpd/isakmpd.conf regulary.

With this (for -3.5, probably) or, for -current, this (yet untested, sorry!) patch applied you may specify an interface name alternatively to an IP address, and isakmpd will then use the first IPv4 or IPv6 address found on that interface. The configuration then looks like:

[Net-local]
ID-type=                IPV4_ADDR_SUBNET
Network=                pppoe0
Netmask=                255.255.255.255

OpenBSD IPSEC and NAT

If you want to use NAT to hide a LAN behind your single IP address (remember, that's your one and only local address within aboves IPSEC flow), you may simply route the peer network to a local interface and perform NAT on that. Example:
route add -net 244.3.0.0/16 127.0.0.1
and in /etc/pf.conf:
nat on lo0 from any to 244.3.0.0/16 -> pppoe0

MSS Clamping

You should consider configuring MSS clamping for packets that are part of the IPSEC security association. E.g., for tunneled mode, with the configuration outlined above, and connected via PPPoE, the typical packet looks like:
Ethernet payload, 1500 octets
PPPoE/PPP header, 8 octets PPPoE/PPP payload, 1492 octets
IP header, 20 octets IP payload, 1472 octets
ESP header, 8 octets IPSec payload, encrypted, 1436 octets
IP header, 20 octets IP payload, 1416 octets
TCP header, 20 to 64 octets TCP payload, 1396 to 1352 octets
ESP trailer, 28 octets

which basically means that something like

scrub in all max-mss 1396 no-df
in /etc/pf.conf might be a helpful. Well, you'll better limit that to the actual IPSEC flow, but hopefully you've got the idea.

Take care, that particular value not be suitable for other ESP authentication algorithms.


 Made with VI 
 Valid CSS 
 Valid HTML 4.0 
 NO ePATENTS 
 Datenschutz 
 Impressum