IPSec with DNSSEC v2

Back to our business. On 11 Oct a patch to enable DNSSEC protected DANE CERTs was merged to StrongSWAN's upstream so now you can have interoperability between racoon and strongswan if you need to use CERTs for easy deployment.

The approach is pretty the same, only with StrongSWAN you have additional DNSSEC validation (racoon blindly trusts underlying DNSSEC implementation).

For simplicity we'll use racoon configuration part from the previous example, and here're just StrongSWAN specifics. Bare minimum to work with racoon then would be:

# strongswan.conf - strongSwan configuration file
charon {
    threads = 16
    plugins {
        dnscert {
            enable = true
        }

    }
}
libstrongswan {
    plugins {
        unbound {
            resolv_conf = /etc/unbound/resolv.conf
            dlv_anchors = /etc/unbound/dlv.isc.org.key
        }
    }
}

Important points are to enable dnscert plugin and configure unbound library to do DNSSEC. Here we assume you use DLV since your TLD is not signed (as eg. .mobi). If it is signed - root key should suffice. Next - IPSec peer configuration

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
        # strictcrlpolicy=yes
        # uniqueids = no
        charondebug = 2

# Add connections here.

conn %default
    leftcert=/etc/ssl/certs/box.pem
    leftsendcert=never
    rightsendcert=never
    leftauth=pubkey
    rightauth=pubkey
    leftid=box.fqdn
    inactivity=0
    keyingtries=%forever
    type=transport

conn vex
    right=vpn.fqdn
    rightid=box.fqdn
    type=tunnel
    auto=start
    keyexchange=ikev1
    esp=aes-sha-modp768!
    ike=aes-sha256-modp1024!

Meh, just tried to reproduce it on my spare ubuntu - couple of things revealed. First - you may nedd to adjust your apparmor profile to allow charon reading some extra files, eg. this way:

/etc/apparmor.d/local/usr.lib.ipsec.charon:
  /etc/unbound/*        r,
  /etc/resolv.conf      r,
  /var/lib/unbound/*    r,

Next - you need to have your local private key for the local peer in a more permissive place than standard /etc/ssl/private - but then it's advicable to encrypt it somehow at least, eg. like this:

# openssl rsa -aes256 < /etc/ssl/private/box.key > /etc/ipsec.d/private/box.aes
<enter and confirm password>
# echo ': RSA box.aes "KeyPassword"' >> /etc/ipsec.secrets

Or, if you decided to switch entirely to strongswan (without racoon) you may finally enjoy ECDSA certs with their shorter size:

# openssl ecparam -genkey -name secp521r1 -noout -out /etc/ssl/private/box.ec.key
# openssl req -new -x509 -key /etc/ssl/private/box.ec.key \
-out /etc/ssl/certs/box.ec.pem
# openssl ec -aes256 -in /etc/ssl/private/box.ec.key \
-out /etc/ipsec.d/private/box.ec.aes
# echo ': ECDSA box.ec.aes "KeyPassword"' > /etc/ipsec.secrets

Now you just need to publish certificate as CERT record in DNS. It's advisable though to not publish more than one cert record for domain name since StrongSWAN cannot yet properly enumerate certificates even thoguh such mechanism is part of the credential manager subsystem. Hence you'd need to replace ECDSA certificate in all apps as well as create/update a TLSA record for this certificate (if required - not everyone yet agreed on which of DANE methods to use *sigh*).

# echo -e "box\t\tIN CERT PKIX 0 4 (" >> zone.file
# openssl x509 -in /etc/ssl/certs/bo.xec.pem | grep -v CERT >> zone.file
# echo ")" >> zone.file
# echo -e "*._tcp.box\t\tIN TLSA 3 1 1\t" >> zone.file
# openssl x509 -pubkey -in /etc/ssl/certs/box.ec.pem -noout | \
openssl pkey -pubin -outform DER | openssl sha256 | \
cut -d' ' -f2 >> zone.file