Client-Specific Override Not Being Assigned

amartin

Hello,

I am running pfSense 2.2.3 with OpenVPN configured as follows:

Server Mode: Remote Access (SSL/TLS + User Auth); user auth connects to an AD server
Device Mode: tun
Strict User/CN Matching: <unchecked>- Tunnel Network: 132.0.0.0/21

I have client-specific overrides configured for different CNs (since this uses AD authentication the CN is the user's username) like this:

user1: 132.0.0.4/30
user2: 132.0.0.8/30
user3: 132.0.1.56/30

This has been working well, but today user3 connected and was assigned 132.0.0.6 as his IP address. Thus he had access to all of user1's firewall rules. This is a problem. There appear to be two issues here:
1.) why did it not use his client-specific override? the CN value in the override matched the CN value for his connection on the OpenVPN Status page
2.) why would OpenVPN assign a subnet from a different client-specific override? Can't it see that the other subnet is reserved for a different client-specific override?

Is it that you just need to keep the "dynamic" range for OpenVPN leases separate from the client-specific override ranges? If so, how can you do that since I assume both must be included inside of the "Tunnel Network"? Thanks!</unchecked>

marvosa

Post the commands in each CSO.

amartin

Do you mean the settings in one of the CSO entries? If so, all I have set are the Common name (e.g. user1), Description, Tunnel Network (e.g. 132.0.0.4/30), and Enable NetBIOS over TCP/IP options. Everything else is blank/unchecked. What else should I post?

divsys

As Marvosa suggested, an actual screenshot of each of the CSO's would be helpful.
They are usually pretty simple, but sometimes what we think we've entered and what has actually happened can show up to a "third party".

One other CSO -gotcha to watch out for, every now and then I end up with a leading/trailing space in CN field.
The entry "looks" OK, but never matches as can be seen in the OpenVPN status logs.

amartin

Here are the two CSOs from the config:

                <openvpn-csc><custom_options><common_name>user1</common_name>
                        <block><tunnel_network>132.0.0.4/30</tunnel_network>
                        <local_network><local_networkv6><remote_network><remote_networkv6><gwredir><push_reset><netbios_enable>yes</netbios_enable>
                        <netbios_ntype>0</netbios_ntype></push_reset></gwredir></remote_networkv6></remote_network></local_networkv6></local_network></block></custom_options></openvpn-csc>                 
              <openvpn-csc><custom_options><common_name>user3</common_name>
                        <block><tunnel_network>132.0.1.56/30</tunnel_network>
                        <local_network><local_networkv6><remote_network><remote_networkv6><gwredir><push_reset><netbios_enable>yes</netbios_enable>
                        <netbios_ntype>0</netbios_ntype></push_reset></gwredir></remote_networkv6></remote_network></local_networkv6></local_network></block></custom_options></openvpn-csc>

What would happen is that user3 would get assigned 132.0.0.6 as his IP address which is a problem for 2 reasons:
1.) it's not matching the CSO for user3
2.) even though it isn't matching, it's still taking user1's assigned /30 rather than a free/available one

Also for reference here is the OpenVPN server config:
http://pastebin.com/wCHrKNq8

divsys

Have you checked "Status->System Logs->OpenVPN" to see if the CSO is actually being applied when the client connects in?
You may have to up the logging verb level in the server.

BTW, why are you using an IP subnet assigned to the US military for your tunnel addresses?
Who knows what your clients DNS/routing table/firewall/???? could do with that assignment…...
Normally one would pick a set out of 10.x.x.x, that's what they're there for ;)

And on a similar vein, do you actually need a /21 subnet for your tunnels, how many clients are you expecting to connect?

amartin

Have you checked "Status->System Logs->OpenVPN" to see if the CSO is actually being applied when the client connects in?
You may have to up the logging verb level in the server.

I tried deleting and re-adding the CSO and now I do see it being applied when the client connects. The more concerning question for me is why even if it wasn't being applied was OpenVPN allowing the client to get assigned an IP in a different CSO's reserved /30? That is the bigger concern I think, since it could inadvertently give different access permissions to a user.

BTW, why are you using an IP subnet assigned to the US military for your tunnel addresses?
Who knows what your clients DNS/routing table/firewall/???? could do with that assignment…...
Normally one would pick a set out of 10.x.x.x, that's what they're there for ;)

Yes, I should fix that :)

And on a similar vein, do you actually need a /21 subnet for your tunnels, how many clients are you expecting to connect?

Yes, I plan on having several hundred CSO's, so I need a pretty large subnet

amartin

The primary concern I have is that the CSO assigned to a different user was handed out to this user when his CSO did not match (for whatever reason). Am I correct in understanding that there is no safety check to make sure that a specific CSO's subnet doesn't get used for just any user? In that case, do I need to make sure that all CSO subnets are at the top of the subnet, so that these "dynamic" allocations happen only at the bottom of the subnet and don't accidentally overlap with the CSOs?

Derelict

If you are going to have that many clients I would suggest one OpenVPN server for dynamic users and at least one for CSO/static users.

amartin

@Derelict:

If you are going to have that many clients I would suggest one OpenVPN server for dynamic users and at least one for CSO/static users.

This would work if there were a way to for an OpenVPN server to only allow connections that have a CSO (no dynamic connections allowed). Is that possible (disabling dynamic users)?

Otherwise the concern I have is even if I setup a separate OpenVPN server for CSOs only, then if a CSO gets accidentally deleted or modified that user could still connect as a dynamic user.

divsys

If you setup a second server (Serv2), simply create a new Certificate of Authority (Ca2) and build a new Server Certificate (Crt2) from Ca2.
Any connections to Serv2 will then require a Certificate created via Ca2 and will not be valid at all for the original OpenVPN Server.

Pro's

completely separated Certificate chains
full isolation of two categories of OpenVPN clients

Con's

two certificate chains to manage

Derelict

I have to do some testing but it appears the tunnel network on the server and the tunnel network in the CSO don't have to be related.

If you were to, say, route 10.15.20.0/23 to OpenVPN I believe you could set the tunnel network to 10.15.20.0/24 and assign CSOs out of 10.15.21.0/24 You'd just need to add an iroute in the CSO (I think). So if there was no CSO they'd get an address out of the dynamic pool and not step on any properly-configured CSOs.

I might be completely wrong though.

amartin

@divsys:

If you setup a second server (Serv2), simply create a new Certificate of Authority (Ca2) and build a new Server Certificate (Crt2) from Ca2.
Any connections to Serv2 will then require a Certificate created via Ca2 and will not be valid at all for the original OpenVPN Server.

Pro's

completely separated Certificate chains

full isolation of two categories of OpenVPN clients

Con's

two certificate chains to manage

The concern I have is what happens if a mistake is made in one of the CSOs for a static client. That static client would still have a certificate with the original CA and thus would still connect to the original OpenVPN server and network. Since CSOs do not appear to be enforced, that client could get assigned the network from another CSO.

@derelict:

I have to do some testing but it appears the tunnel network on the server and the tunnel network in the CSO don't have to be related.

If you were to, say, route 10.15.20.0/23 to OpenVPN I believe you could set the tunnel network to 10.15.20.0/24 and assign CSOs out of 10.15.21.0/24 You'd just need to add an iroute in the CSO (I think). So if there was no CSO they'd get an address out of the dynamic pool and not step on any properly-configured CSOs.

I might be completely wrong though.

Can anyone else confirm if this is a valid configuration? can the "Tunnel network" setting in the OpenVPN server config be completely unrelated to the networks assigned in the CSOs? If so, I think this would be the ideal solution