client config files automatically being created in ccd

[f1lter]

Can anyone shed some light on how/when/why openvpn automatically creates individual client config files in the client-config-dir?

I discovered this when troubleshooting an issue with routes not getting pushed to clients. We had our routes configured in ccd/DEFAULT. The first time a client connected, everything worked fine. But subsequent connections did not get any routing info. After some poking around, I discovered files in the ccd named after the client id, with the following contents: ifconfig-push 10.128.128.x 255.255.255.0

This were apparently overriding the routes in DEFAULT.

This was easily resolved by moving routing directives to the server config file.

That being said, I am still *very* confused about how and why these client config files are being created. Have done a lot of googling and man page reading -- but maybe I'm just missing something very obvious.

My server and client configs are below. They were more or less copied from a config built by a previous sysadmin and have been only slightly modified over time, i.e., I did not build them from scratch and if anyone sees general issues with them, please feel free to point them out.

server
--------

proto udp
port 1194
dev tap0
server 10.128.128.0 255.255.254.0
management 127.0.0.1 5001
tls-server
daemon
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/gateway.crt
key /etc/openvpn/keys/gateway.key
dh /etc/openvpn/keys/dh1024.pem
tls-auth /etc/openvpn/keys/ta.key 0
client-config-dir /etc/openvpn/client-config
mode server
duplicate-cn
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
keepalive 10 120
comp-lzo
push "ping 10"
push "ping-restart 60"
plugin /usr/local/sbin/radiusplugin.so
username-as-common-name
client-to-client
push "dhcp-option DNS 10.12.4.5"
push "dhcp-option DNS 10.12.4.6"
push "dhcp-option DOMAIN dealerdotcom.corp"
push "route 65.183.159.151 255.255.255.255 net_gateway"
push "route 65.183.159.0 255.255.255.0"
push "route 64.70.56.0 255.255.255.0"
push "route 216.69.226.0 255.255.255.0"
push "route 10.10.0.0 255.255.255.0"
push "route 10.13.0.0 255.255.0.0"
push "route 10.10.2.0 255.255.255.0"
push "route 10.11.0.0 255.255.0.0"
push "route 10.12.0.0 255.255.0.0"
push "route 10.128.0.0 255.255.0.0"
push "route 10.39.0.0 255.255.255.0"
push "route 10.39.1.0 255.255.255.0"
push "route 10.37.0.0 255.255.252.0"


client
-------

client
dev tap
proto udp
mute-replay-warnings
auth-user-pass
comp-lzo
verb 3
resolv-retry 10
persist-key
persist-tun
float
nobind
remote [my.ip.address.here]
ca ca.crt
tls-auth ta.key 1
cert client1.crt
key client1.key

[f1lter]

Quick comment on my own post.

I'm sure someone will notice that we're using openvpn in routed mode but using the layer 2 tap device instead of tun (layer 3). We're doing this because we recently switched from bridged to routed mode and we didn't want to have to change 'dev tap' to 'dev tun' in all our client configs... Although I'm of the impression openvpn will still work with tun on one side and tap on the other.

[janjust]

the radius plugin is capable of writing out these files - if the IP address is associated to the user name in the radius backend then the plugin can write out this file.
The proper solution is , indeed, to move routes which need to be pushed to all clients to the main server config.

Also note that it is possible to include config files into config files, e.g. inside 'server.conf' use

Code: Select all

config global-routes.conf

this way you can keep all global routes in a single config file.