On Wed, May 16, 2012 at 17:30 +0400, Pavel Shvagirev wrote:
>
> Thank you very much for the detailed reply. It helped a lot, though I
> have something to add.
>
> > 6) Transfer 10.5.0.1.zip to the Windows host and load the certificates
> > by doubleclicking on them.
> You should not import the cert by doubleclicking on it - it will import
> to the current user's facility instead of a local computer. That will
> cause 13806 errormessage telling that there is no appropriate computer
> certificate etc. MMC and the local computer account switch should be
> used instead.
>
Yes, I admit I have just tested the possibility of installing
certificates and hoped that user certs will work just fine.
We have a tool to do the right thing automatically, so I didn't
bother to test this part. Shame on me (:
> > 7) Configure iked to do RSA auth w/o EAP (for the start):
> >
> > ikev2 "win7" passive esp \
> > from 192.168.0.0/24 to 192.168.1.0/24 local any peer any \
> > srcid 10.1.0.1 \
> > config address 192.168.1.100 \
> > config name-server 192.168.0.1
> >
> > Here, 192.168.0.0/24 is a network client is getting access to,
> > 192.168.1.0/24 is a "DHCP"-like network from which client is
> > getting an ip address (192.168.1.100 specifically). Please
> > note, that the code to turn this awkwardness into real (DHCP-like)
> > address pool specification is not written yet. Note that srcid
> > has to match the host that the certificate is issued to, otherwise
> > windows will refuse to connect.
> >
> > Once you do that you can load iked and see that it hooks up the
> > server certificate (in the iked -dvv output that is).
> This is the most intriguing part :)
>
> ikev2 "win7" esp \
> from 172.16.2.0/24 to 0.0.0.0/0 \
> peer 10.0.0.0/8 local 192.168.56.0/24 \
> eap "mschap-v2" \
> config address 172.16.2.1 \
> tag "$name-$id"
>
> This example is from the man page. `config address' is in the range of
> `from source', not from the destination subnet. Are you sure it sould be
> like you said?
>
Yes, I'm sure. The syntax was changing over time but in the end the
"from" network is always the network behind the host running iked
regardless of whether it's initiator or responder. Here's a config
I use at the moment for my testing:
ikev2 "win7" passive esp \
from 10.1.0.2 to 10.1.0.5 local any peer any \
srcid 172.23.55.126 \
config address 10.1.0.5 \
config name-server 10.1.0.2
10.1.0.2 is configured as "ifconfig lo1 10.1.0.2/24" on openbsd.
Man page should be updated.
> How do I manage the `DHCP-like' addresses? Is this address range where
> the client should be granted an IP from OR is that a client's local
> private network? I found that dhcpd cannot run on enc0 interface. How do
> you manage that?
>
No, DHCP is NOT involved at all. IKEv2 does it itself. I said that you
can only configure one IP address per "ikev2" rule atm and the address
pool code is not written (but it should/will be).
> Now the negotiation seems to be complete but still the connection can
> not be established due to various reasons:
>
> 1. Windows side stops on error #31 "Attached device is not working
> properly" (looks like a Windows problem though). Have you seen that?
>
Nope.
> 2. Doesn't work EAP mode - Windows stops on "Checking username and
> password" error. Then #13803, 1931...
>
Well, as I said, try certificates first. Disable EAP.
> > If someone thinks that this might be turned into some sort of a
> > howto or FAQ entry or whatever, please feel free to reuse any
> > piece of text. Attribution is welcomed but not required.
> Your instructoins really did the trick - I got rid of those anoying
> troubles that were caused by strictly following the manuals... I think
> it should have been written in more detail, covering in detail _every_
> network part (with its role) that participate in the negotiation. 'cause
> sometimes it has contradicting points. Probably it is a matter of
> individual perception, nevertheless I had what I had as well as tons of
> others struggling with that in mail lists across the web =)
>
Everyone is encouraged to contribute to this thread so that we can
work out an unambiguous instruction.
> Thanks.
>
> --
> Best regards,
> Pavel Shvagirev
> skype: pavel.shvagirev