epSOS PPT - VPN setup
The epSOS trusted node infrastructure implements the core epSOS security services that ensure the confidentiality of medical data transmission and the availability and authenticity of epSOS services:
- virtual private network (VPN) on top of the public internet
- message encryption (TLS) and integrity protection
- mutual NCP authentication
The establishment of mutual trust between nodes is performed by IPSec [RFC 4301]. A gateway-to-gateway VPN MUST be set up between all epSOS nodes.
For testing purposes, we setup a VPN server matching epSOS requirements using Openswan. The target platform must be a GNU/Linux with a not too old kernel. We are using a 2.6.38-amd64 one. Openswan must be a recent version (>=2.6.33).
If this version is not available (as in Debian), you will have to compile it, modifying some options in Makefile.inc :
- As we are not using NSS stuff, we have not enabled USE_LIBNSS
- Certificates signatures digests must be enabled with USE_EXTRACRYPTO
- If the kernel is an amd64, uncomment USERCOMPILE?=-g -O3 -m64
- then a make programs install should install the latest version
Port 500 must be accessible with UDP protocol, from NCP gateways (all Internet in a first step) to this Linux machine. If this machine has a resolved name, put it in TSL as access point, otherwise just use IP. This access point will be your ID and will be used in configurations (on all VPN servers), so try to not modify it.
Check that ipsec verify is at last as good as :
# ipsec verify Checking your system to see if IPsec got installed and started correctly: Version check and ipsec on-path [OK] Linux Openswan U2.6.35/K2.6.38-2-amd64 (netkey) Checking for IPsec support in kernel [OK] SAref kernel support [N/A] NETKEY: Testing XFRM related proc values [OK] [OK] [OK] Checking that pluto is running [OK] Pluto listening for IKE on udp 500 [OK] Pluto listening for NAT-T on udp 4500 [OK] Two or more interfaces found, checking IP forwarding [OK] Checking NAT and MASQUERADEing [OK] Checking for 'ip' command [OK] Checking /bin/sh is not /bin/dash [WARNING] Checking for 'iptables' command [OK] Opportunistic Encryption Support [DISABLED]
You will need your VPN certificate and key in DER format, one .der for the certificate and one .key for the key (with a password).
All certificates in DER format should then be copied in /etc/ipsec.d/certs.
The global Openswan configuration is stored in /etc/ipsec.conf :
# /etc/ipsec.conf - Openswan IPsec configuration file
# This file: /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual: ipsec.conf.5
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# we use netkey as it's included in kernel
protostack=netkey
# Do not set debug options to debug configuration issues!
# plutodebug / klipsdebug = "all", "none" or a combation from below:
# "raw crypt parsing emitting control klips pfkey natt x509 dpd private"
# eg:
# plutodebug="control parsing"
# we use plutodebug to fix connection errors...
#plutodebug="raw crypt parsing emitting control klips pfkey natt x509 dpd private"
#
# enable to get logs per-peer
#plutoopts="--perpeerlog"
#
# NAT-TRAVERSAL support, see README.NAT-Traversal
# we enable it but not sure if it's useful...
nat_traversal=yes
# exclude networks used on server side by adding %v4:!a.b.c.0/24
# not sure if it should be set or not
#virtual_private=%v4:131.254.209.20/32
# OE is now off by default. Uncomment and change to on, to enable.
# default value
oe=off
# default value
nhelpers=0
# default value
interfaces=%defaultroute
# Add connections here
# a global server.conf then a conf file per country
include /etc/ipsec.d/*.conf
The VPN key is known to ipsec using /etc/ipsec.secrets :
: RSA vpn-server.key password
The key file must be stored in /etc/ipsec.d/private, "password" must be replaced by the real password.
A file will hold the common properties to all connections, we named it server.conf, stored in /etc/ipsec.d :
conn %default
# use RSA based authentication with certificates
authby=rsasig
# right side is the other country, left is us
# other country key is stored in its certificate
rightrsasigkey=%cert
# my side is left - the openswan security gateway
left=131.254.209.20
# the VPN server certificate name
leftcert=_ih_VPNGateway_0.der
# we will use rsa key specified by the certificate
# the key will be find using ipsec.secrets previously configured
leftrsasigkey=%cert
# id of the server, with @ before
leftid=@sake.irisa.fr
# ?
keyingtries=1
# disable compress (?)
compress=no
# ?
disablearrivalcheck=no
# transport mode as required by epSOS
type=transport
# ?
auth=esp
_ih_VPNGateway_0.der (ie your VPN server certificate) will be found in /etc/ipsec.d/certs
Now, for each country, we will add a <country code>.conf that will set up a country connection.
For instance, this what we have for Denmark :
# dk will be the identified of the connection conn dk # right is the host of their VPN server right=77.243.52.137 # the certificate that they use for their VPN server rightcert=_dk_VPNGateway_0.der # the ID of their VPN server - must be the same as in their conf rightid=@test01.epsos.netic.dk # connection is not started on ipsec start, started by hand auto=add # ? pfs=yes
The certificate is in /etc/ipsec.d/certs.
The Danish certificate is signed by their CA, and this CA MUST be added in /etc/ipsec.d/cacerts in DER format, otherwise it will NOT work!
It seems that's a common practice to include the CA in TSL using the NCP-B IdV certificates, usually the second one. So the certificate NCPB__<country code>_IdV_1.der has a good chance to be the CA.
A connection will work only if both countries share the same logical configuration (can be different in plain text).
ipsec command controls Openswan one it is started :
- ipsec whack --status : list configurations and connection states
- ipsec auto --verbose --up <country code> : starts a channel
- ipsec auto --verbose --down <country code> : stops the channel
To get more logs, you can set protolog to all in ipsec.conf, and then tail /var/log/auth.log.
Some points are still investigated, like routing and automatic generation of configuration files.