is the only missing keyword, OpenVPN client-to-server config need to work correctly on the client.
It took me 3 days to figure this out, a lot of RTFM’ing and head-banging.
Full client config looks this way:
[ad#ad-lb]
tls-client
pull
remote vpn.xxx.xxx
dev tun
ifconfig 10.0.232.2 10.0.232.1
cert [full-path-to-client’s-CRT-file]
key [full-path-to-client’s-KEY-file]
ca [full-path-to-server’s-CA-CRT-file]
comp-lzo
persist-key
persist-tun
Server config is similar:
port 1194
proto udp
dev tun
ca ca.crt
cert vpn-server.crt
dh dh1024.pem
server 10.0.232.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push “route 192.168.232.0 255.255.255.0”
client-config-dir ccd
push “dhcp-option DNS 10.0.232.1”
keepalive 10 120
comp-lzo
max-clients 10
user nobody
group daemon
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 3
there’s nothing and in ccd/client.
The worst thing was, i could find no solution for My-Link-Not-Working on the Internet:
Both ends use ‘tun’, the subnets are set correctly, i could even see packets arrivint to the VPN end on port 1194.
But no traffic on ‘tun0’, no ping, no connection. That was kind of strange. I was already to swith to ‘tap’ adapter and proceed to bridging, but fortunatelly i’ve read what ‘pull’ means in OpenVPN – “This option must be used on a client which is connecting to a multi-client server. It indicates to OpenVPN that it should accept options pushed by the server, provided they are part of the legal set of pushable options (note that the –pull option is implied by –client ).”
No idea why, but:
routes were correctly set on both ends;
the firewall was not an issue both on Linux and windows sides;
the magical “pull” made the work done.