1

Another probably daft question: I am in the process of setting up a VPN connection for the purpose of remote access to services on my home LAN. The router, firewall and VPN server i am using for this is a Draytek Vigor 2865. My biggest problem here is choosing a VPN protocol/understanding IPSec.

I have successfully setup a PPTP VPN, which works fine. Draytek setup as server, a couple of user accounts on the Draytek with unique usernames and passwords which can be used to connect to the VPN, and i can change various settings on a user based basis. (I.E i could assign specific dial-in users a specific IP). However, i know PPTP is not the most secure option. Really, for my needs, PPTP with maximum MPPE encryption and strong passwords would probably be fine, but i would rater use the better option if it is available.

Here are the dial-in options in the draytek: VPN options in the Draytek

Obviously, i am trying to avoid PPTP. I don't want to use OpenVPN, because i need to be able to use the built in Windows VPN client, and i don't think, from what i understand, SSL VPN is what i want here either. That leaves IPsec tunnel or L2TP (With IPsec).

What i really don't understand about IPSec is that it seems to use a "Pre shared key" for authentication, and i don't quite know how this works. Does every remote user login with the same PSK? In which case how can you distinguish remote users on the server end? It would make sense if a PSK was used IN ADDITION to a user/pass, but in some cases it seems just a PSK is used... (Example of this: https://draytek.co.uk/support/guides/kb-teleworker-smartvpn-ipsec)

Would you recommend the IPsec tunnel option, or is L2TP with IPsec nice and secure? Which option does the Windows VPN client support?

Sorry for the long post, any advice would be appreciated.

M_D
  • 373
  • 1
  • 11

1 Answers1

0

What i really don't understand about IPSec is that it seems to use a "Pre shared key" for authentication, and i don't quite know how this works. Does every remote user login with the same PSK? In which case how can you distinguish remote users on the server end?

In the original protocol (IKEv1), you indeed cannot. (Though it's not strictly true that it always uses a PSK – certificates are preferred, and do allow distinguishing users by the certificate's metadata.)

This omission was solved in several different ways:

  1. Cisco added a custom modification for their "IPsec VPN" to allow user/password authentication as a second step (and I think they renamed the PSK to "Group key"). That's the "Xauth" option in your router.

    I'm not sure what apps you'd use to connect to Xauth VPNs from Windows (there's strongSwan on Linux and Android).

  2. Microsoft instead chose to tunnel another VPN protocol inside the IPsec-secured tunnel – the IPsec PSK is used to protect L2TP, which then allows performing the same PAP/MSCHAP/EAP authentication as in PP(T)P. That's "L2TP with IPsec Policy" in your router.

    Windows has this built in, but since it's two different protocols tied together, Linux setup can get complex.

  3. Finally, the newer protocol version – IKEv2 – has built-in solutions. First, clients can send an "initiator ID (IDi)" which acts nearly as a user name; different initiators can have different PSKs (or even completely different configurations).

    Second, IKEv2 natively supports EAP auth including MSCHAPv2, which will also transmit usernames as part of EAP. (This is essentially the Xauth extension made official.)

    Windows 10+ has built-in client support for IKEv2; for Android I'd use the strongSwan app.

(Another thing missing from stock IKEv1 is automatic assignment of client IPs, which is also added by all of the above extensions.)

Would you recommend the IPsec tunnel option, or is L2TP with IPsec nice and secure? Which option does the Windows VPN client support?

IKEv2 is the modern choice, where supported – I would pick "IKEv2 EAP" if I needed different user accounts, as that's what Windows supports.

Anything that's built on IKEv1 is a bit stale, and I think the PSK in IKEv1 directly contributes to the encryption of the tunnel, so it must be strong – not a password but a random key or passphrase. Still, if set up properly, it is more secure than MPPE.

(I wouldn't worry about it using MSCHAPv2 – in all of the above modes, user authentication is done inside an already encrypted tunnel, unlike with PPTP which did it in the clear, so it could as well be just a regular password and it'd still be secure.)

and i don't think, from what i understand, SSL VPN is what i want here either

That depends. "SSL VPN" is not a single protocol, it's a very broad description for many different products that involve SSL (TLS, DTLS) as their basis, but usually in different ways. For example, Cisco AnyConnect is an "SSL VPN" product but it's not compatible with any other "SSL VPN" except itself.

In fact, Microsoft itself has a TLS-based VPN protocol – SSTP – which is natively supported by Windows and is overall fairly secure; as secure as a regular TLS connection, that is. So if you have that as an option you could certainly use it instead of IKEv2. (Though it has a small downside in that it's TCP-based; TCP-inside-TCP is not ideal.)

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • Good answer, thanks! I think i will attempt to setup IKEv2 EAP, and see how i get on. Failing that i will try L2TP with IPsec. – M_D Aug 03 '23 at 14:57
  • Just tried this and encountered an error. I have seen that some places say that you have to create a DWORD in the registry, because NAT is causing a problem. See here: https://learn.microsoft.com/en-US/troubleshoot/windows-server/networking/configure-l2tp-ipsec-server-behind-nat-t-device. Does this apply if it is only the client that is behind NAT? (Obviously my server is my router, so not behind NAT) – M_D Aug 03 '23 at 16:08
  • I'm not entirely sure (never used L2TP in Windows myself), but I believe it's common to both sides; the Windows L2TP/IPsec client does not enable NAT traversal mode by default. (IPsec originally uses ESP for its data channel, which is difficult to NAT and most home routers don't handle it. Although ESP-over-UDP did exist in IKEv1, there were some problems with it.) – u1686_grawity Aug 03 '23 at 16:18
  • (keep in mind that Windows has *two* IPsec clients – the old one for IKEv1 including L2TP/IPsec, and the new one for IKEv2 including "IKEv2 VPN", with different capabilities; the latter should be fine with NAT) – u1686_grawity Aug 03 '23 at 16:20
  • So i gave SSL VPN a go with the Draytek smart VPN client, because i thought installing a piece of software is still better than having to edit the registry. However, the SSL VPN failed. I then edited the registry, re-setup an IKEv2 VPN connection, which still fails. Funny thing is PPTP has not ceased to work at all: Both with the windows client and even in the Draytek client. Not quite sure what is going on here, perhaps something to do with the fact i am using my phones 4G to test the connections? Incidentally, how secure, really, is PPTP with strong passwords and max MPPE? Acceptable? or no? – M_D Aug 03 '23 at 17:03
  • As far as I know, the way MSCHAPv2 works, it's equally crackable regardless of password strength (as it divides the password _hash_ into chunks and crams it into plain DES, which means one just needs to crack DES twice to obtain the NT hash, which is probably ~1 week of CPU time?) You decide whether that's acceptable. Now MSCHAP _over EAP-PEAP_ would be stronger (PEAP is literally TLS) and would provide a strong key for MPPE... MPPE is still RC4 and has its own issues, though. – u1686_grawity Aug 03 '23 at 17:31
  • I'd try getting IKEv2 to work (it should not have as many NAT problems as IKEv1). – u1686_grawity Aug 03 '23 at 17:33
  • Right, i have now had L2TP/IPsec working without any registry editing. However, when i try IKEv2, i get the "The network connection between your computer and the VPN server could not be established because the remote server is not responding etc..." error. I have tried the registry edit, which does not seem to have helped. Bit stumped here, any ideas appreciated. – M_D Aug 04 '23 at 09:48