Bug #1417
closedOpenVPN client specific overrides doesnt work by default
Added by Raffael Schmid over 13 years ago. Updated about 13 years ago.
100%
Description
Hi
I wanted to use the "client specific overrides"-feature. But it didn't push the configuration until I put the following content into the "Advanced configuration" of the OpenVPN-Server:
mode server;client-config-dir /var/etc/openvpn-csc;
Did I missconfigure something? Or how should this really work?
Updated by Raffael Schmid over 13 years ago
yeah, dunno how to change the attributes... :) I'm talking about an installation inside kvm with 2.0 rc1.
Updated by Chris Buechler over 13 years ago
- Category set to OpenVPN
- Status changed from New to Feedback
- Target version set to 2.0
- Affected Version set to 2.0
I know for a fact this works without doing that, need more info.
Updated by Raffael Schmid over 13 years ago
I have the following content in the client specific configuration.
ifconfig-push 10.10.0.2 10.10.0.1;iroute 192.168.0.0 255.255.255.0;
I just didnt get these pushed when I didnt have the content mentioned above. But I can't understand how this could work for you?
I mean there is no
client-config-dirparameter in the default configuration? I thought, that you have to put this in there to have openvpn read in the other directory?
Updated by Jim Pingle over 13 years ago
What exact settings are you using for your OpenVPN server?
I just set up an instance with the wizard and it does have this in the config:
client-config-dir /var/etc/openvpn-csc
It would be helpful to either have screencaps of the configuration and/or the OpenVPN section of your config.xml
Updated by Jim Pingle over 13 years ago
Strike that. Looking at the backend code, you must be using "Peer to Peer (SSL/TLS)". It seems that one case was missing from the test for putting that line in the config. Commit will be coming shortly.
Updated by Jim Pingle over 13 years ago
- % Done changed from 0 to 100
Applied in changeset 02d99511539a3312f8aab54b7dd1cdcaec9c0847.
Updated by Jim Pingle over 13 years ago
- Status changed from Feedback to Closed
Apparently it's just not allowed to have a shared key tunnel and push with client-config-dir. Backing out changes, as it's an invalid config.
Updated by Raffael Schmid over 13 years ago
Hm, okay. But I use certificate based authentication....
So please reopen?
Updated by Chris Buechler over 13 years ago
- Status changed from Closed to Feedback
that commit looks like it would have been ok, it was changed for P2P TLS, not shared key.
Updated by Jim Pingle over 13 years ago
Yeah I had the wording in that wrong. There may be something else going on in P2P/TLS then. People on the forum were seeing errors with both the original fix for this and my other changes:
Updated by Raffael Schmid over 13 years ago
For me, the client-config-dir works with the build "Fri Apr 15 18:54:32 EDT 2011". I didn't upgrade yet.
I read the thread and it looks like if you select "Peer to Peer (SSL/TLS)" as "Server Mode", you need to add the param and otherwhise let it off?
Or maybe easier if you put "--server mode", you just add "--client-config-dir" as well?
Updated by Jim Pingle over 13 years ago
OK, I finally got it all the way straightened out. I confirmed it worked between two test VM networks with my last commit ( 0cc5ab4 ).
Updated by Bill Fenner about 13 years ago
Part of the last commit ( 0cc5ab4 ) broke my previously-working site-to-site p2p_tls vpn configuration using a /30. With the server line and tun, OpenVPN gripes that it needs a /29; even when I reconfigure it to use a /29 it doesn't work, as the server thinks it is .1 and the client is .2, while the info that it pushes to the client is that the client is .3 and the server is .4, so the client adds its route to .4, which goes over the tunnel to the server and the server doesn't recognize it as a packet that it should accept.
Updated by Jim Pingle about 13 years ago
What exactly did you have entered for the Tunnel Network? It works fine when entering a proper value (a /30 where the start is the subnet ID, such as x.x.x.0/30, x.x.x.4/30, etc) and not the IP you expect that side to have.
Updated by Bill Fenner about 13 years ago
We used 172.25.0.0/30, and OpenVPN gripes as follows:
Jun 2 07:55:09 tfw1 openvpn60992: Options error: --server directive when used with --dev tun must define a subnet of 255.255.255.248 (/29) or lower
Jun 2 07:55:09 tfw1 openvpn60992: Use --help for more information.
It worked before the change that you made to include the "server" line in the configuration.
If I remove the line:
server 172.25.0.0 255.255.255.252
from the config file, it now gripes that --client-config-dir requires --mode server:
Jun 2 08:03:34 tfw1 openvpn18560: Options error: --client-config-dir/--ccd-exclusive requires --mode server
Jun 2 08:03:34 tfw1 openvpn18560: Use --help for more information.
As I mentioned, this same config worked great from -BETA4 through -RC1 before the change to add "server" and "client-config-dir".
Updated by Jim Pingle about 13 years ago
Ah, ok. I was thinking of a shared key and /30.
The main reason most people want to use p2p+tls is to push settings to the client side and use CSCs for iroutes. To push settings, you need the server directive. To use the server directive, you need to use at least a /29 since it needs to be able to accept at least two clients. Typically p2p shared key setups are used for connecting together many sites and pushing routes, so using it with a /30 doesn't make much sense there.
How was it routing the traffic back to the client side of that connection without an iroute for the connecting certificate's common name?
If that really was working with routed two-way traffic (no NAT) I suppose we could add another mode that doesn't use the server directive. Not sure what we'd call that, though. "Peer to Peer (SSL/TLS, no CSC)" perhaps. It really isn't as useful as using the SSL/TLS mode, and all you need to do is use a larger subnet.
Updated by Bill Fenner about 13 years ago
I suppose I was using p2p+tls because it was the option that was selected when I clicked "add VPN server", not because I had a particularly good reason to use it. Traffic was routing back because of the "remote network" setting on the server side:
<vpnid>1</vpnid>
<mode>p2p_tls</mode>
<protocol>UDP</protocol>
<ipaddr/>
...
<tunnel_network>172.25.0.8/30</tunnel_network>
<remote_network>172.18.16.0/20</remote_network>
<local_network>172.16.0.0/12</local_network>
I've switched to peer-to-peer (shared key) and my /30 is happy again, and as we grow we'll probably switch to a bigger network with p2p+tls and multiple clients.
Rather than introduce a new mode, how about checking the netmask? If someone naively configured a /30 on p2p_tls, like I did, just skip adding the server and client-config-dir options.
case 'p2p_tls':
/* Allow a legal, but silly with p2p_tls, /30 */
if ( $mask != '255.255.255.252' ) {
$conf .= "server {$ip} {$mask}\n";
$conf .= "client-config-dir {$g['varetc_path']}/openvpn-csc\n";
}
(P.S. With the /29 and p2p_tls, the route that got pushed by the server got installed incorrectly on the client -- no csc, just the "local network" setting on the p2p_tls server page, but that'd be the subject of a different conversation)
Updated by Jim Pingle about 13 years ago
Well the remote network only adds a route, typically with SSL/TLS it requires an iroute to assocate that route to a given certificate. Perhaps OpenVPN internally handles that when given a /30.
I'm hesitant to automatically switch modes based on the subnet mask, seems prone to user error/surprise, but if that is how OpenVPN itself operates that may be a safe method.
EDIT: Or perhaps without the server directive, it needs no iroute. Not sure why I didn't think of that before hitting 'save'...
Updated by Bill Fenner about 13 years ago
The last section of http://backreference.org/2009/11/15/openvpn-and-iroute/ explains that there are situations where you don't need an iroute if you have only one client.
You know that if you hand OpenVPN a "server ..." configuration with a /30 that it'll just gripe that it needs more room, so there's no real harm in changing the config file generation when it's a /30. At worst, it'll turn from one non-working configuration to a different non-working configuration; at best, it'll let the naive user who set up his tunnel in a silly way that worked with -BETA4 upgrade to 2.0 and continue to work, even if it's silly.
Updated by Jim Pingle about 13 years ago
Yeah that's a fair point. I'll look into adding a check on the subnet mask side and tossing out the server/csc lines if it's too small. Should be fairly easy.
Updated by Jim Pingle about 13 years ago
I committed the change to check the CIDR and if it's 30+, it will not use the server/client-config-dir directives. Should hopefully do the right thing for you. It will be in the next new snapshot or you can gitsync and try it, or apply the commit by hand. It's shown on the commit list for this ticket above.
Updated by Chris Buechler about 13 years ago
- Status changed from Feedback to Resolved