OpenVPN Disconnects every 5-10 minutes
-
@BlueKobold:
Fri Aug 07 15:40:36 2015 [customerSRVCA] Inactivity timeout (–ping-restart), restarting
Could it be that you should shorten the lease time of this connection or that this connection is not
interrupted after xxx minutes of being idle?You mean the keep alive command???
To be honest, it is our first time that so much users, use the VPN. Normally it is 2-3 users, now it are 5-15 users who randomly logon to the VPN.
-
now it are 5-15 users who randomly logon to the VPN.
Perhaps the hardware is not capable of more users?
-
It's a new server, so it should be capable of doing that. If I look at the stats, cpu usage is 1-10% and memory is 23% so it is not in full load :-)
Do you need more information?
-
I checked it again today and found this:
Jul 30 09:30:58 php-fpm[77172]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGW.I guess it started here, but don't know what it means?
-
Jul 30 09:30:58 php-fpm[77172]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGW.I think that this VPN endpoints got a new IP address by or from their ISPs!
They have dynamic IPs and no static (fixed) ones or a DynDNS account! :-\I guess it started here, but don't know what it means?
For setting up VPNs you should be sure that both endpoints of a VPN connection are
sorted with static IP addresses or DynDNS accounts. If this will be so called road worrier
set ups or the VPN endpoints will be mobile clients this might be not worse and is running
smooth but if the VPN endpoints are also pfSense firewalls or VPN Servers this will be then
a problem. :o -
@BlueKobold:
Jul 30 09:30:58 php-fpm[77172]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGW.I think that this VPN endpoints got a new IP address by or from their ISPs!
They have dynamic IPs and no static (fixed) ones or a DynDNS account! :-\I guess it started here, but don't know what it means?
For setting up VPNs you should be sure that both endpoints of a VPN connection are
sorted with static IP addresses or DynDNS accounts. If this will be so called road worrier
set ups or the VPN endpoints will be mobile clients this might be not worse and is running
smooth but if the VPN endpoints are also pfSense firewalls or VPN Servers this will be then
a problem. :oThe pfsense (OpenVPN Server) is connected to a modem which has a static WAN IP.
The clients are indeed laptops/desktops with the OpenVPN application with a dynamic ip. But I can't imagine they change ip every 5 minutes :).
Yesterday I got sick of it and rebooted the pfsense. After this the VPNclients stayed connected for over an hour (maybe 2). But now it's back to reconnecting like every 5 minutes :(.
-
But now it's back to reconnecting like every 5 minutes
You can have a closer look to the OpenVPN settings and search the lease time for the
given internal IP, after connecting to the OpenVPN server. But not on the client side. -
you mean the vpn ip? I have no idea how I should do that?
here is my server.conf file
dev ovpns1
verb 3
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 udp
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 192.168.200.2
tls-server
server 10.221.14.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' true server1" via-env
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'CustomerSRVCA' 1 "
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 10.220.14.0 255.255.255.0"
push "dhcp-option DOMAIN local.customer.be"
push "dhcp-option DNS 10.220.14.82"
push "register-dns"
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo no
persist-remote-ip
float
topology subnet -
Okay, did some more testing.
Created a new OpenVPN server, changed it to TCP port 1195.
Looks like a breakthrough, now it is connected for almost 3 hours without a disconnect.
It doesn't make sense though…
I'll keep you posted
-
After hours of testing it looks solved.
We are slowly going to update the clients their vpn files to the new port.
Can someone tell me this is even possible? Is this solution even recommended?
-
Well using a port other than the default 1194 is definitely possible and if it solves your problem, I'd say it's advisable…
I often use ports other than 1194 for OpenVPN if only to avoid conflicts/blocking/port spying/etc.
Just a guess on my part but your scenario could easily involve ISP "managing" OpenVPN traffic or possibly some DOS/malware/spying trying out your OpenVPN port.
-
Well using a port other than the default 1194 is definitely possible and if it solves your problem, I'd say it's advisable…
I often use ports other than 1194 for OpenVPN if only to avoid conflicts/blocking/port spying/etc.
Just a guess on my part but your scenario could easily involve ISP "managing" OpenVPN traffic or possibly some DOS/malware/spying trying out your OpenVPN port.
A possibility yes. But not sure.
I've putted the 2 mac clients on another server, maybe it's them (don't have a lot of experience with MAC clients)
But it still works like a train, so client is happy and we are happy ;-) !
Thanks all!
-
@CM350 Changing from UDP to TCP also worked for me. Same port is fine. But I think the ISP may have been have been having issues with UDP.