On 04/06/2018 04:51 PM, Mick wrote:
Domestic grade routers which offer IKEv1, typically use PSK for authentication, not TLS certificates. The PSK is what IKE uses in userspace to establish a secure connection with authentication between peers for the purpose of exchanging the IPSec keys to encrypt the tunnel with.

ACK All of that makes sense. Thank you for clarifying / confirming what I suspsected was the case.

I don't /remember/ IKE being involved in what I was doing. But there's a chance that it was happening without me being aware of it.

If you check the 2nd sentence in the wiki page below, it confirms MSWindows L2TP/IPSec uses IKEv1 to exchange the IPSec keys:


I don't remember L2TP being involved either. But that doesn't mean that it wasn't.

If memory serves (and it often does not) I was manually configuring IPSec policies via a GPEdit snapin. It was extremly low level and obtuse to configure.

OpenSWAN was forked into LibreSWAN and FreeSWAN is now called StrongSWAN. Anyway, part of the IKEv2 standard is to offer support for mobile and multihomed users (MOBIKE).

Hum. I've not payed attention to *SWAN as I've not needed to use it. I also thought that IPSec was a LOT more complicated than other technologies. Plus, I was dealing with more road warrior type things than site-to-site. (It's my understanding that IPSec is (or was) not really friendly for mobile.)

Although IKE operates in userspace, the IPSec stack is in kernelspace and its performance superior to userspace VPN technologies.

My understanding is that IKE was just used to boot strap and maintain the in kernl IPSec. Thus IKE could easily run in user space.

Apparently Wireguard is even more efficient than the IPSec's xfrm/netkey, but I have not tried it out yet.

I've not messed with Wireguard yet. But it's on my list if I ever need / want to mess with VPNs.

Grant. . . .
unix || die

Reply via email to