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

Alex mysqlstudent at gmail.com
Sat Sep 20 04:18:26 EEST 2014


Hi,

>> - 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

Using these instructions, it looks like I need the following to
recreate the CA and certs for each side:

# Create a certificate authority
# certutil -S -k rsa -n "ExampleCA" -s "CN=Example CA Inc" -v 12 -t
"C,C,C" -x -d /etc/ipsec.d
# Create a user (host) cert for  both sides:
# certutil -S -k rsa -c "ExampleCA" -n "user1" -s "CN=User Common
Name" -v 12 -t "u,u,u" -d /etc/ipsec.d

So after running these commands, the certs and CA is in cert8.db,
key3.db and secmod.db, correct?

I can then export the CA and import it on the other side. Should I
just recreate both host certs on the other side as well?

And this automatically creates 2048-bit keys?

So no actual certificate files are necessary, as they are with older openswan?

Is there a way to test this setup with just one side using libreswan
and the other side using the ancient 1024-bit keys? I'd like to be
able to test this before rebuilding both sides from scratch because
they're currently in production and separated by a driving distance.

Do I need to worry about NAT traversal for the one side that's using a
192.168. network, or is that done automatically?

>> - 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 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?
I'm wondering because I didn't have the friendlyname in the secrets
file and I'm pretty sure the connection was established, as I was
pretty sure I was able to connect to the remote side.

Or does this AUTHENTICATION_FAILED message clearly indicate I wasn't connected?

>> 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.

So if it's loaded the private key, does it mean it's the correct
private key, and that it's using it for this connection?

>> 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?

That is the new key that I just generated, which the other side has no
knowledge about.

>> conn %default
>
>>        leftrsasigkey=%cert
>>        rightrsasigkey=%cert
>
> So you are using X.509.... So the raw RSA keys are not used.

Does that mean the secrets file is 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:

Since you mentioned they are probably just 1024-bit, and since they
are expiring at the end of the year anyway, I figured I could follow
the steps for building a CA, as I've outlined above.

> 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.

I've run --listall, and it looks like it found two keys but can't parse them?

000 List of Pre-shared secrets (from /etc/ipsec.secrets)
000     1: RSA (none) (none)
000     1: RSA (none) (none)

The /etc/ipsec.secrets file just includes all the *.secret files from
/etc/ipsec.d. This includes the one I just created and the original
one without the friendlyname.

Perhaps I don't fully understand the purpose of the secrets file.
That's where the preshared keys are stored, correct? And I'm using
X.509 certs, so the keys aren't used?

Thanks,
Alex

>
>> # 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


More information about the Swan mailing list