I am trying to make use of the ccd feature to allow routing back to the client network as well. The basic configuration works fine. From the client side, I can ping anything on the server's LAN. From the server side though, even on the vpn server itself, I cannot connect in any way to anything on the client side except the tunnel endpoint. I'll note too that the server doesn't seem to be properly configuring the routes, but even doing that manually doesn't help.
The network layout is something like this:
Client LAN: 10.0.0.0/8
Client LAN IP: 10.0.1.1/24
Client VPN IP: Dynamically assigned
Server LAN: 192.168.0.0/24
Server LAN IP: 192.168.0.1/24
Server VPN IP: 172.16.0.1/24
When the client connects, the relevant/interesting log entries look good:
us=101380 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route-gateway 172.16.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 172.16.0.3 255.255.255.0'
us=101446 OPTIONS IMPORT: timers and/or timeouts modified
us=101462 OPTIONS IMPORT: --ifconfig/up options modified
us=101476 OPTIONS IMPORT: route options modified
us=101490 OPTIONS IMPORT: route-related options modified
us=101505 Preserving previous TUN/TAP instance: tun0
us=101521 Initialization Sequence Completed
On the server side though, I get this:
us=969122 184.108.40.206:48940 [match] Peer Connection Initiated with [clientip]:48940
us=969320 match/220.127.116.11:48940 MULTI: Learn: 172.16.25.3 -> client/[clientip]:48940
us=969441 match/18.104.22.168:48940 MULTI: primary virtual IP for client/[clientip]:48940: 172.16.25.3
us=16684 match/22.214.171.124:48940 PUSH: Received control message: 'PUSH_REQUEST'
us=16825 match/126.96.36.199:48940 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route-gateway 172.16.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 172.16.0.3 255.255.255.0'
Looks good right? But I get not even a hint of trying to do the server-side configuration changes necessary to setup the routing appropriately. In the startup debug dump I see that it is at least picking up the config data:
us=790655 route 10.0.0.0/255.0.0.0/nil/nil
us=795342 client_connect_script = '[UNDEF]'
us=795380 learn_address_script = '[UNDEF]'
us=795419 client_disconnect_script = '[UNDEF]'
us=795457 client_config_dir = 'ccd'
us=795495 ccd_exclusive = DISABLED
But then I get down a little further and I see this:
us=816841 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
us=816881 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.0.0.0
Is this the expected behavior for this kind of configuration? Should it dump this error? I used to have a config similar to this on a prior 1.x release of openvpn that worked splendidly, but for some reason I can't get it to work now. If anyone has some hints on this I'd appreciate it. If I add the route manually (in this case ip route add 10.0.0.0/8 via 172.16.25.3) I still can't route to the remote network. If I start up tcpdump on the remote end and start throwing packets at it I never see anything show up there. But return routed traffic gets through fine. (Note: I have also completely dropped the firewalls on both ends to make sure it wasn't a firewall issue.)
(Note: I snipped generic things from the config like local/remote/ca/log/etc)
server 172.16.25.0 255.255.255.0
push "route 192.168.0.0 255.255.255.0"
route 10.0.0.0 255.0.0.0
keepalive 10 120
tls-auth /etc/openvpn/server/ta.key 0
iroute 10.0.0.0 255.0.0.0
tls-auth /etc/.openvpn/ta.key 1