On Thu, Oct 04, 2012 at 06:13:13AM +0200, Erling Westenvik wrote:
> Shamefully I must admit what many OpenBSD'ers consider a crime worse
> than intercourse with the devil, namely to follow a so-called "Howto"
> (http://www.mouedine.net/) and within minutes having my daughters
> Windows 7 road "warrior" up and running connected to my OpenBSD gateway
> using IKEv2.
>
It is not a crime to follow external How-Tos, but I think the common
problems are
a) they might have mistakes that everyone blindly copies
b) they can be outdated describing an old version of the code
c) they're sometimes too specific or complicated for the actual use case
I didn't find any "bugs" in the mouedine How-To and mikeb@ helped to
create it, so I think it is OK. The ikeca.cnf-part is actually
optional, it just simplifies the configuration a bit by asking less
questions.
> Luckily for those that think natively in man pages, I'm stuck with how
> to achieve the same thing with my OpenBSD real road warriors, so now is
> your chance to tell me off.
>
> On the gateway the following /etc/iked.conf works for the win7 client:
>
> # cat /etc/iked.conf
> ikev2 passive esp \
> from 192.168.3.0/24 to 10.10.10.0/24 local a.b.c.d peer any \
> srcid a.b.c.d \
> config address 10.10.10.7
>
> I've generated certificates for one of my OpenBSD clients:
>
> # ikectl ca vpn certificate t500 create (+ export)
>
For using OpenBSD as a client, the name "t500" MUST match the srcid of
the peer, which is either an IP address or a FQDN or even the local
hostname of "t500". It will be embedded in the certificate as
subjectAltName and signed by the CA, so it is not just a "name". The
remote system will compare the subjectAltName in the certificate with
the supplied ID of the peer.
AFAIK, this doesn't matter for Windows clients since they use IDs of
type ASN1_DN that don't use the subjectAltName check but compare the
X.509/ASN.1 distinguished name. We only support ASN1_DN IDs on the
responder/server side, not for OpenBSD-clients. Even for Windows
clients, it is a good practice to use a real FQDN or IP address as the
"name" for ikectl certificates.
> copied them to the client and extracted them according to ikectl(8):
>
> # tar -C /etc/iked laptop -xzpf t500.tgz
>
> which brought /etc/iked on the laptop to contain:
>
> ./ca/ca.crt
> ./certs/t500.crt
> ./crls/ca.crl
> ./export/ca.pfx
> ./export/t500.pfx
> ./private/t500.key
> ./private/local.key
> ./local.pub
>
> What is difficult to derive from the multitude of man pages from this
> point onward, is:
>
> 1) how to add the client to /etc/iked.conf on the gateway.
We currently only allow one policy for roadwarriors ("peer any"). Any
connection will match your server rule above when setting up the IKE
SA. This means that it generally doesn't make sense to specify a
"config address" field for a policy that can match multiple clients.
We also don't support config address pools yet.
> 2) how to configure and start the client.
>
The client's iked.conf would be reversed like this:
ikev2 active esp \
from 10.10.10.0/24 to 192.168.3.0/24 peer a.b.c.d \
srcid t500
Note that the iked.conf(5) manpage says: "If srcid is omitted, the
default is to use the hostname of the local machine, see hostname(1)
to set or print the hostname." This is theoretically true, but there
is a bug in recent releases that broke this auto-setting based on the
hostname. It will be fixed in -current and the next release, so
please specify srcid for now, even if it matches the configured
hostname. This is the certificate bug that mikeb@ was mentioning in
another mail here.
Have fun with iked!
Reyk
