[Swan] Building site-to-site from old systems

[Paul Wouters]

On Thu, 18 Sep 2014, Alex Regan wrote:

> - The RHEL7 site-to-site VPN docs say to place the leftrsasigkey and 
> rightrsasigkey directly into the config file. I've been working with openssl 
> to generate pkcs12 files from the key, certificate, and certfile. Then I'm 
> using p12util to import the pkcs12 files directly into the NSS database. Is 
> there any difference between the two methods?

Yes, those are two different methods. One is called "raw keys
authentication" and the other one is "X.509 certificate based
authentication". Both methods can use RSA keys.

An example with raw RSA keys can be seen:

https://libreswan.org/wiki/Host_to_host_VPN

An example with X.509 certificates:

https://libreswan.org/wiki/Using_NSS_with_libreswan#Using_certificates_with_NSS

You seem to be using the X.509 method.

> # openssl pkcs12 -export -out righthost.example.com.p12 -inkey 
> remotecerts/orion.key -in remotecerts/righthost.crt -certfile 
> CA/newcerts/righthost.pem -name 'righthost'
> # openssl pkcs12 -export -out left.example.com.p12 -inkey 
> hostcerts/lefthost.key -in hostcerts/lefthost.crt -certfile 
> hostcerts/lefthost.crt -name 'lefthost'
>
> # pk12util -i righthost.example.com.p12 -d /etc/ipsec.d
> # pk12util -i lefthost.example.com.p12 -d /etc/ipsec.d
>
> - The keys, certs, and certificates are pretty old, and expiring at the end 
> of the year. How do I recreate them for libreswan?

If you want to re-use them, you can use your existing CA to re-sign
them again. But if they are old, they are most likely 1024 bit keys
with sha1, you might want to consider generating larger RSA keys (2048
bit keys) and perhaps use sha2 instead of sha1.

> - I'm seeing the following message when pluto starts:
>  AVX2 or AES-NI instructions are not detected.
> Is that a limitation of the processor? It's a Xeon E3-1220 v2, so I would 
> think it would have support for this?

It apparently does not have the support? See
http://en.wikipedia.org/wiki/AES_instruction_set#Supporting_CPUs

> - I'm also seeing the following message on the new fedora20 side after the 
> connection is set up:
> Sep 18 20:51:01 vpntest pluto[4492]: "MYVPN" #1: unable to locate my private 
> key for RSA Signature
> Sep 18 20:51:01 vpntest pluto[4492]: "MYVPN" #1: sending notification 
> AUTHENTICATION_FAILED to 65.1.11.6:500

If you have imported the pkcs#12 file, you still need to place a line
in ipsec.secrets to tell pluto about the private key. It uses the 
"friendly" name used when creating the pk12 file:

: RSA "friendlyname"

And in ipsec.conf you would have a left and/or right cert line, eg:

 	leftcert=friendlyname

> I have two secrets files - one I just created with ipsec newhostkey and I 
> believe is wrong, and an existing hostkey.secrets file that was created years 
> ago, which I believe is correct. It also references both files during 
> startup:
>
> Sep 18 21:03:14 vpntest pluto[1256]: loading secrets from 
> "/etc/ipsec.secrets"
> Sep 18 21:03:14 vpntest pluto[1256]: loading secrets from 
> "/etc/ipsec.d/hostkey.secrets"
> Sep 18 21:03:14 vpntest pluto[1256]: loaded private key for keyid: 
> PPK_RSA:AQPAcYrhb

This seems to be one private key.

> Sep 18 21:03:14 vpntest pluto[1256]: loading secrets from 
> "/etc/ipsec.d/righthost.example.com.secrets"

This might not have loaded as expected?

> conn %default

>        leftrsasigkey=%cert
>        rightrsasigkey=%cert

So you are using X.509.... So the raw RSA keys are not used.


> conn MYVPN

> 	leftid="@C=US, ST=New Jersey, L=MyTown, O=My Company Inc, 
> CN=lefthost.example.com"
> 	leftcert=lefthost

> 	rightid="@C=US, ST=New Jersey, L=MyTown, O=My Company Inc, 
> CN=righthost.example.com"
> 	rightcert=righthost

So you seem to be loading both certs on both ends. That means you do not
need to use a CA. But it also means you need to import those two
certificates into NSS on both sides. So to install your certificates
and keys, do this:

on lefthost:
import import /file/lefthost.p12
certutil -A -i /file/righthost.crt -n righthost -d /etc/ipsec.d -t ""

on righthost:
import import /file/righthost.p12
certutil -A -i /file/lefthost.crt -n lefthost -d /etc/ipsec.d -t ""

Don't forget the ipsec.secrest entry as described above. After starting
openswan/libreswan, run: ipsec auto --listall to see if you have both
certificates and one private key on each end.

> # Disable Opportunistic Encryption
> include /etc/ipsec.d/no_oe.conf

You can remove that and use oe=no in "config setup" on openswan. You
do not need oe= for libreswan.

Paul