For When You Can't Have The Real Thing
[ start | index | login ]
start > SuperStack3 VPN with Radius

SuperStack3 VPN with Radius

Created by dave. Last edited by dave, 13 years and 116 days ago. Viewed 3,383 times. #2
[diff] [history] [edit] [rdf]

Using Radius as a supplemental authentication method on VPN connections

Unfortunately this is beginning to look like a non-starter.

The current hurdle is that the VPN setup on the SS3 only permits radius authentication in two cases:

  • Group VPN: The problem with GroupVPN is that it does not do much in the way to increase security. If we enable radius, it means that all a departed employee has to do is to know _one_ username password combination, and he's in. At least with the current setup we can close his door on him at the firewall. Going the Group VPN route would mean that a new Group VPN .spd file would have to be distributed once a user left, which creates its own logistical and potential security problems.
  • IKE with pre-shared secret: This fails because you cannot set up a IKE profile without either a static remote IP address (in this case, the connecting client -- and the idea of a roving client is that they have no way to predict in advance what their IP address will be) and/or some kind of remote network and subnet (the VPN rofile stubbornly refuses to be enabled without one defined, I was using, which corresponds to my personal network at home).
Derek tells me that he has spent much time trying to work around the static-remote-address limitation without success, and it looks like we are stuck with it.

I also note in the Tundra documentation that the Group VPN is the only way Windows XP will work, so we may be forced to face the limitations of Group VPN sooner or later.

On the Radius side of things, I did more testing with the FreeRadius setup and am not happy with the way it evaluates access permissions -- there is no simple way to only permit a certain group access. (Perversely, there _is_ a simple way to exclude certaing groups access, but explicit-denial/implied-permission is not the correct way to go.) I have joined the mailing list for FreeRadius and see if there is a way to do this.

As a work-around, Neil accepted a variant of the cvspass process, where a cronjob creates a custom passwd file based on nis group membership, and FreeRadius using only that custom passwd file for access decisions. (Note this variant has not been completed yet, but since cvspass is written it should take all of 10 minutes to do.)

However, since we seem to be jammed up with this static-client-address requirement, I don't see much more to try here.

Unless anyone else has ideas?

one comment (by dave) | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful: | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt