Re: [Openvpn-users] OpenVPN 2.0, single server, multiple clients, access control without CRL

[James Yonan <jim@xxxxxxxxx>]

On Tue, 3 May 2005, Roland Turner (SourceForge) wrote:

> I've been using OpenVPN 1.0 for a while and am about to switch to 2.0. I'd
> really like to take advantage of the single server feature (no need to
> allocate port numbers to users, no need to mangle firewall configurations
> per-user), but don't want access control to depend upon a CRL. Can this be
> achieved?

Yes, use "client-config-dir" in combination with "ccd-exclusive".

> I also want a particular one of the clients to appear through
> its own tun device for seperate firewall treatment, is this possible in
> the single-server context?

Server mode only supports one shared TUN/TAP interface.

If your only reason for wanting to do this is access control, then see the 
HOWTO for an example of how to assign fixed IP addresses to specific 
clients and then firewall based on the source IP address.

> My concern about the use of the CRL is that I'd prefer to allow access on
> a prohibited-unless-permitted basis rather than a
> permitted-unless-prohibited basis not only because that is good practice,
> but because of the risk of someone forgetting to add the CN of a departing
> user to the CRL (combined with the difficulty of having a subsequent audit
> pick this up; a difficulty that does not arise if a list of all permitted
> users is present). As far as I can tell, 2.0's PKI implementation does not
> allow me to provide an explicit list of authorised CNs, all that it can do
> is treat all certs signed by the CA as valid, except for those listed in
> the CRL (in other words, for anyone who has ever been an employee, or at
> least who has been an employee within the last, say, year, access is
> permitted-unless-prohibited).

No, client-config-dir/ccd-exclusive is provided precisely for this reason.

You still might need a CRL, however, if you want to revoke a cert and 
reissue a new one using the same common name.

> More broadly, managing even a minimal CA is
> an overhead that I could do without.

Well you can get away from the CA requirement by doing everything with
static tunnels.  Most people prefer the 2.0 server model exactly because
managing a minimal CA is generally more straightforward than dealing with
multiple static tunnels.

> At first blush the ccd/ sub directory
> and/or the --auth-user-pass-verify mechanisms appear to offer some hope,
> but I can't see a straightforward way to achieve what I have in mind. (The
> --auth-user-pass-verify mechanism doesn't appear to provide information
> about the cn of the cert used to authenticate.

Not true.  Either the tls-verify or auth-user-pass-verify plugin/script
has access to the CN, and can use it as a basic for the
authorization/denial decision.

> and it's not clear to me how
> the ccd/ mechanism handles authentication for clients which have no
> subdirectory.)

If ccd-exclusive is set, the authorization will fail.  If ccd-exclusive is
not set, then a file called "DEFAULT" will be read if present.  If
"DEFAULT" is not present, then no file will be read, meaning that all
parms will default to how they are specified in the main server
configuration file.

> What I'd really like to do is to store a static key per
> user, but still share the same UDP port.

There's no direct support for that in 2.0, aside from the ability to set
up multiple static tunnels as supported by 1.x.  It's not clear to me why
you would want this since the whole point of TLS is to automate the
problem of dynamic distribution of session keys.  So if OpenVPN were to
support a client-server mode with static keys, it would essentially be
reinventing TLS, but doing it badly since the keys would not automatically
change once per hour.

> The special firewall treatment for one client is tied up with an
> assumption that the OpenVPN server is not validating the sender IP
> addresses on inbound datagrams, so filtering by IP address on the firewall
> would not be adequate (an adversary could, in principle at least, falsify
> sender IP addresses). If a seperate tun device cannot be allocated for a
> single client, can such filtering be performed on a per-datagram basis in
> the server, or do I really to run a seperate OpenVPN instance on a
> seperate UDP port?

In TUN mode, the OpenVPN server validates all source IP addresses on
incoming tunnel packets according to client, so the source IP address can
be used in firewall rules.  In TAP mode, the same can be accomplished,
with somewhat more complexity, by using a learn-address script/plugin.

For example, in TUN mode, if a client connects and is given a VPN IP 
address of 10.20.0.6, then any client -> server packet having a source IP 
address not equal to 10.20.0.6 will be dropped.  If the client has a 
subnet behind it, the server configuration (via --client-config-dir) must 
specify an "iroute" directive so that the server knows which source IPs 
to expect from the client.

James



____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users