pfSense

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

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

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

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.

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

So please reopen?

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

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?

OK, I finally got it all the way straightened out. I confirmed it worked between two test VM networks with my last commit ( 0cc5ab4 ).

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.

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.

We used 172.25.0.0/30, and OpenVPN gripes as follows:

Jun 2 07:55:09 tfw1 openvpn⁶⁰⁹⁹²: 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 openvpn⁶⁰⁹⁹²: 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 openvpn¹⁸⁵⁶⁰: Options error: --client-config-dir/--ccd-exclusive requires --mode server
Jun 2 08:03:34 tfw1 openvpn¹⁸⁵⁶⁰: 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".

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.

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)

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'...

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.

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.

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.