L2TP over IPSec?
-
There is a bunch of confusing info out there e.g.
http://forum.pfsense.org/index.php/topic,49166.msg260600.html#msg260600
http://redmine.pfsense.org/issues/475
but most of it is rather old, and seems to stem from the 2.0 time, which means BSD 8.1 or 8.2, not 8.3So two questions:
What does/doesn't the L2TP as it exists in 2.1 do?
For what OS release is this planned to be fixed?L2TP over IPSec is kind of important, because it's pretty much the preferred VPN access for anything Apple (iOS, OSX), and clients are very easy to set up.
-
It doesn't work, and likely will not any time soon.
iOS and OSX support PSK (or RSA)+xauth fine, no need for L2TP. Android also does xauth.
The problem is the way L2TP+IPsec clients set the identifier. They use their IP, which is random and unknowable except in static IP setups (which makes it all but useless for mobile clients). The clients, when using L2TP+IPsec, don't offer a way to change that (At least none I found at the time did).
To accept Pre-Shared keys paired with such identifiers means you need to patch racoon to accept wildcard pre-shared keys, which is a security risk.
All of the tutorials floating around out there require that step as well, and the racoon developers won't accept those patches into their tree precisely because of that risk.
-
The problem is the way L2TP+IPsec clients set the identifier. They use their IP, which is random and unknowable except in static IP setups (which makes it all but useless for mobile clients). The clients, when using L2TP+IPsec, don't offer a way to change that (At least none I found at the time did).
To accept Pre-Shared keys paired with such identifiers means you need to patch racoon to accept wildcard pre-shared keys, which is a security risk.
All of the tutorials floating around out there require that step as well, and the racoon developers won't accept those patches into their tree precisely because of that risk.
Hm…
...why wildcard preshared keys and not wildcard IP identifiers?All the mobile client setups I know use 0.0.0.0/0 as their identifier, precisely because the address of a roaming client isn't known. But as long as they know the preshared key then that's good enough. It's not any different than using slogin from an arbitrary IP address, the only thing one needs to know is the username and password, which if concatenated isn't any more secure than a preshared key of sufficient length.
There are always more and less secure methods, so I don't get why the racoon people won't do what's an industry standard, just because it's less secure than some other method that's an alternative. -
Wildcard PSK is really Wildcard identifier, same deal there, just worded differently.
Not sure if that is a true standard, but it's been discussed several times on the ipsec-tools-devel list, feel free to take it up with someone there.
http://comments.gmane.org/gmane.network.ipsec.tools.devel/2196
http://marc.info/?l=ipsec-tools-devel&m=128146451115746 (same as above, different view)That thread has more of the reasoning behind why it's a bad idea.
-
I'll have to wrap my head around the xauth thing they are talking about, right now I'm not groking it…
...aside from the fact that of course, if I know all configuration details I can spoof a server; but why would I give untrusted users access to trusted resources in the first place? I wouldn't have people VPN into the net that I want to protect if I can't trust them with the keys to do so. Also, there's the concept of encrypted configuration files that are being pushed e.g. to phones and other roadwarrior-type clients, which the users can't inspect, which would seem to me to also mitigate that issue.Still, what I really think should be done, is to have the wildcard thing to be a configuration option. It's off by default, but you can turn it on at our own peril. I mean, we have other things along these lines on the System: Advanced:* pages, where one can, to suit particular requirements, enable/disable potentially problematic behaviors.
