Project

General

Profile

Actions

Bug #1417

closed

OpenVPN client specific overrides doesnt work by default

Added by Raffael Schmid almost 13 years ago. Updated over 12 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
OpenVPN
Target version:
Start date:
04/05/2011
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.0
Affected Architecture:

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?

Actions #1

Updated by Raffael Schmid almost 13 years ago

yeah, dunno how to change the attributes... :) I'm talking about an installation inside kvm with 2.0 rc1.

Actions #2

Updated by Chris Buechler almost 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.

Actions #3

Updated by Raffael Schmid almost 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-dir
parameter in the default configuration? I thought, that you have to put this in there to have openvpn read in the other directory?

Actions #4

Updated by Jim Pingle almost 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

Actions #5

Updated by Jim Pingle almost 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.

Actions #6

Updated by Jim Pingle almost 13 years ago

  • % Done changed from 0 to 100
Actions #7

Updated by Jim Pingle almost 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.

Actions #8

Updated by Raffael Schmid almost 13 years ago

Hm, okay. But I use certificate based authentication....

So please reopen?

Actions #9

Updated by Chris Buechler almost 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.

Actions #10

Updated by Jim Pingle almost 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:

http://forum.pfsense.org/index.php/topic,35865.0.html

Actions #11

Updated by Raffael Schmid almost 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?

Actions #12

Updated by Jim Pingle almost 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 ).

Actions #13

Updated by Bill Fenner almost 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.

Actions #14

Updated by Jim Pingle almost 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.

Actions #15

Updated by Bill Fenner almost 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".

Actions #16

Updated by Jim Pingle almost 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.

Actions #17

Updated by Bill Fenner almost 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)

Actions #18

Updated by Jim Pingle almost 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'...

Actions #19

Updated by Bill Fenner almost 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.

Actions #20

Updated by Jim Pingle almost 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.

Actions #21

Updated by Jim Pingle almost 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.

Actions #22

Updated by Chris Buechler over 12 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF