OpenVPN Packet Corruption
-
I have had a pfSense install working great for the past 6 months, but a few weeks ago ALL of our road warriors are experiencing packet corruption (TCP TUN).
I restarted pfSense, I made a new UDP TUN server, new CA, a new user, and a new certificate for the user. I tried to connect and I had the same problems. HTTPS sites don't load due to certificate corruption, remote desktop doesn't work, normal websites take 4-5 refreshing to load correctly. I have no idea why it is just this one site when I have 20 other installs setup the same way and none of them have failed like this yet.
I get no errors in the OpenVPN logs and NO errors in the Client OpenVPN logs.
Installed Packages:
Snort
iperf
mtr-nox11
OpenVPN Client Export
vnstat2I have tried everything short of a complete re-install. Does anyone know what I should try next?
-
So, you are doing full tunnel then? Post your server1.conf.
-
Here you go:
dev ovpns1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto tcp-server cipher AES-128-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 10.1.10.100 tls-server server 10.2.20.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc username-as-common-name auth-user-pass-verify /var/etc/openvpn/server1.php via-env tls-verify /var/etc/openvpn/server1.tls-verify.php lport 443 management /var/etc/openvpn/server1.sock unix push "route 10.2.15.0 255.255.255.0" push "dhcp-option DOMAIN business.local" push "dhcp-option DNS 10.2.15.5" push "dhcp-option DNS 8.8.8.8" ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024 tls-auth /var/etc/openvpn/server1.tls-auth 0 persist-remote-ip float
-
I upgraded to 2.0.3 and the random corruption has disappeared. I will report back if anything changes. Overall a very wierd occurance. I have a few dozen installs setup the same way on versions 1.2.3 to 2.0.3 and have never had this issue, ever.
-
Glad it's working. It looks like you're using split tunnel, so my thought was it had to be on the client end, but you're also double NATing and using port 443 instead of 1194… that probably has something to do with it.
Also, I'm curious to know why you're pushing out google DNS with a split tunnel deployment.