Hi everyone,
I've got a pfsense router (FreeBSD) running openvpn. I can get any Linux client to connect and route traffic properly from pretty much anywhere...a locally bridged (on the router) public address block, a VPS in Germany, etc. I can get a Windows 7 x86_64 client to connect to the openvpn server, but it won't ping anything on the other side of the tunnel or otherwise route traffic. The setup I've got is thus: my IP subnets arestructured to be compatible with a VLSM summarized route block...essentially I'm taking a class c private subnet and subnetting it classlessly into 4 subnets which I'm locally routing with said PfSense router in a summarized route statement. It works great except for Windows (wow, what a surprise).
Server Conf:
dev ovpns1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 50.78.208.113
tls-server
server 192.168.34.128 255.255.255.192
client-config-dir /var/etc/openvpn-csc
tls-verify /var/etc/openvpn/server1.tls-verify.php
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 5
push "route 192.168.34.0 255.255.255.0"
push "dhcp-option DNS 192.168.34.58"
push "dhcp-option DNS 50.78.208.121"
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.2048
comp-lzo
persist-remote-ip
float
Windows 7 client conf:
client
dev tun
proto udp
remote charon.shortesys.net 1194
resolv-retry infinite
persist-key
persist-tun
cipher AES-128-CBC
ca ca.crt
cert atlas.crt
key atlas.key
comp-lzo
I'm pretty much ruling out problems with firewall rules on the router, routing sets on the router, and client firewall at this point because: Linux clients work just fine, so no firewall or routing issues on the router. Client firewall software is extremely chatty so I'd see the block attempt, and I also get the same results with the firewall disabled.
I'm guessing it's a route that's not getting pushed to the client, or a gateway that's not getting set up on the client, but I'm at a loss as to how to prove/fix that...and I'm not entirely sure that it isn't something completely different, so I'm open to all advice.
Your help is greatly appreciated!
-Herald
