[Swan] Building tunnel specifically for DNS

Paul Wouters paul at nohats.ca
Tue Oct 2 23:34:42 UTC 2018


On Mon, 1 Oct 2018, Alex wrote:

> I got it to work for one host-to-host tunnel using the URL above
> between the remote system (arcade) and one local system (mail03), but
> having a problem adding a second host (orion). arcade is the right
> side in both configs.
>
> I'm attempting to do this:
>
> [arcade] --------------------- [orion]
>            \
>             \
>              [mail03]

It is not entirely clear what you mean with this. If you mean that
you want orion to contact mail03 via arcade, and you want encryption
only between orion and arcade, you would use on arcade and orion:

conn mail03-orion
 	left=arcadeIP
 	leftid=@arcade_mail03
 	leftrsasigkey=0x....
 	leftsubnet=mail03IP/32
 	right=orionIP
 	rightid=@orion_mail03
 	rightrsasigkey=0x....
 	authby=rsasig
 	auto=start

You generate RSA keys on arcade and orion using:

 	ipsec newhostkey

Then you use ipsec showhostkey --ckaid XXXX --left (or --right) to get
the values needed for the above leftrsasig=/rightrsasig= values.

It also assumes that arcade has a route to mail03, and that mail03
either has its default route via arcade or has a host route for orion
via arcade.

> orion also has a net-to-net VPN with a different set of systems using
> certs.

That's fine, just use a different leftid/rightid so that it becomes
obvious which connection is which.

> It's been some time since we set it up and I've forgotten
> exactly how we did it, but it involved certutil, not just ipsec to
> generate keys.

Yes, https://libreswan.org/wiki/HOWTO:_Using_NSS_with_libreswan

> Is there something different that has to be done when adding a second
> host? Perhaps it's getting confused as to which key to be using?

If using raw RSA/ECDSA keys, you can re-use them on different connections,
even when using different IDs. But if one connection uses certs and the
other uses raw keys, you should give the connections a different ID so
libreswan can pick the right connection.

> How do I list all the certs in the NSS database? On orion, where I
> used certs to build a net-to-net VPN, I can use "certutil -K -d
> /etc/ipsec.d", but on arcade, where I just followed the doc above, it
> fails with SEC_ERROR_LEGACY_DATABASE. Both systems are fedora28.

The NSS errors from certutil are terrible and not helpful with respect
to misspecifying the db directory.

To list all certificates:

certutil -L -d sql:/etc/ipsec.d

> How do I list all the keys that were created using ipsec?

certutil -K -d sql:/etc/ipsec.d

(on Debian use -d sql:/var/lib/ipsec/nss)

> Is it important for the leftid and rightid to be unique throughout
> /etc/ipsec.conf?

In general, yes they should be different. The only exception is if you
have multiple tunnels that will re-use the same IKE SA. In that case,
they can be the same because the IKE SA is shared. IKE SA's can be
shared if the authentication mechanism is identical and only the
left/right subnets and/or left/right protoports are different.

So in your case, since one conn uses certificates and the other raw
keys, the IKE SA cannot be shared and you should give unique IDs
to not confuse the two conns that cannot share the IKE SA.

> Can you provide the steps to do this using certs?

The above link should work for that.

> Also, it's necessary to add --ckaid to the ipsec showhostkey command
> that is not made clear in the wiki doc.

The --ckaid is used to select the key. So if you issue

 	ipsec showhostkey --list

You will get a list of keys, indexed by CKAID. If you want to see
the public key of a particular keypair, use:

 	ipsec showhostkey --ckaid XXXXX --left (or --right)

Note that speciying left/right only changes the string output to be
leftrsasigkey= or rightrsasigkey=. the actual public key output is
the same.

For a configuration file, you can specify the local key by either
its ckaid using leftckaid= / rightckaid= or you can specify it by
public key using leftrsasigkey= and rightrsasigkey=

But the remote key cannot be specified by ckaid, because it is not
present in the remote's NSS database (only its own keypair)

Paul



More information about the Swan mailing list