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

Alex mysqlstudent at gmail.com
Tue Sep 23 03:05:25 EEST 2014


Hi,

>> So no actual certificate files are necessary, as they are with older
>> openswan?
>
> Correct. libreswan does not use /etc/ipsec.d/private or
> /etc/ipsec.d/certs/ and does not need to use /etc/ipsec.d/cacerts/
>
>> Is there a way to test this setup with just one side using libreswan
>> and the other side using the ancient 1024-bit keys?
>
> You can always use your existing certificates and import those instead
> of creating new ones. If you create new ones, you will have to export
> it to pkcs12, then extract the pkcs12 into separate files to get the
> key/cert/cacert to install on the openswan endpoint. Unless your
> openswan endpoint is rhel/centos based in which case it already supports
> nss so you can then just use pk12util to import it.

That's exactly what I ended up doing. Actually, what I did was import
the existing certs into libreswan and just go head-first into it
without testing, and it worked. I was concerned the old freeswan setup
was so old that it wouldn't have supported the new key/cert.

So now I have the old certs that are going to expire at the end of the
year. Now that both sides are fedora20, I should be able to just
recreate new certs on each side and import both on both sides,
correct?

One problem I did have along the way was when I tried to run "ipsec
showhostkey --right", it would report the same key as when --left was
provided instead.

>> I did have this in the ipsec.conf that I pasted here originally. Is
>> this secrets file used when it's configured to use X.509 certificates?
>
> Yes, it used to make a reference between the certificate and the private
> key inside the nss database. We are working on no longer requiring that,
> but for now you still need that : RSA entry in ipsec.secrets even if the
> private key actually lives in the nss db and not in a
> /etc/ipsec.d/private file.

Yes, much simpler now. When you had originally said to create a
hostkey.secrets file with the ": RSA friendlyname" in it, I thought
you meant in addition (appended to) to the hostkey.secrets file, where
all the rest of the RSA key info is located. That caused all kinds of
problems until I figured out the private key was also stored in the
NSS databases.

It appears my processor indeed doesn't support AES/AVX2. How much
overhead is required in software that otherwise would have been done
by the processor?

Sep 21 16:04:08 vpngx  kernel: [   10.096811] AVX2 or AES-NI
instructions are not detected.
Sep 21 16:04:08 vpngx  kernel: AVX2 or AES-NI instructions are not detected.

You've been very helpful, thanks so much.
Alex


More information about the Swan mailing list