OpenVPN connections keep dropping

[bartjsmit]

Mine is rock solid on an admittedly lightly loaded AMD Phenom 9650 quad core with 4GB RAM:

Remote Access (SSL/TLS + User Auth)
Local Database
tun UDP 1194
TLS authentication with static key
Local CA
DH 2048
AES-256-CBC
SHA256
no hardware crypto
cert depth one (client+server)
adaptive compression enabled
redirect gateway
IPv4 and IPv6 tunnel networks
internal DNS and NTP
advanced option: push "route-ipv6 2000::/3"

Clients:
Cyanogen 13.1.5 Android OpenVPN Connect 1.1.17 (build 76)
macOS Sierra Tunnelblick 3.6.6

[minime]

Not stable with:

Remote Access (SSL/TLS + User Auth)
Local Database
tun UDP 443
TLS authentication with static key
Local CA
DH 4096
AES-256-CBC
SHA512
Intel RDRAND engine - RAND
cert depth one (client+server)
Strict User/CN Matching deactivated
Redirect Gateway activated
Concurrent connections empty
Compression: No Preference (if I deactive I can't get a connection established)
Inter-Client communication activated
Duplicate Connections activated
IPv6 is disabled
Dynamic IP activated
Address Pool activated
Topology activated
DNS Default Domain deactivated
DNS Servers defined
Force DNS cache update activated
NTP Servers deactivated
NetBIOS Options deactivated
Client Management Port deactivated
Use common name deactivated
Advanced Configuration: keepalive 150 450
Verbosity level 1
Renegotiate time empty


Client:
OpenVPN for Android 0.6.63 (Arne Schwabe)

[woo]

This may come from using TOTP if you are using it.

yeah, as I wrote two posts further up.. I know that the automatic restart fails due to the OTP. This was clear to me from the beginning, and expected.
I do NOT know, why the connection drops at all, as long as there is active traffic, and the keepalive ping settings are reasonably short (10 seconds in my case). Even less do I know why the connection drops at such regular intervals. My users are working remotely via RDP, so there is always a constant stream of data, since RDP regularly sends "nothing changed" update packets if the screen is idle.
I am trying to find out, whether that's a result of some settings that OPNsense are using for their OpenVPN implementation, or whether I'm lacking certain settings on my clients, or anything that I'm missing which prevents me from actually using OpenVPN@OPNsense in our production environment.

[woo]

Just out of pure chance, I noticed something in the (i) help for the OpenVPN server settings, specifically the Renegotiation Time: "Renegotiate data channel key after n seconds (default=3600).
When using a one time password, be advised that your connection will automatically drop because your password is not valid anymore."
Now if THAT isn't the reason for my dropped connections, I don't know what else is.
This side effect might need being made a little more public, don't you think? It de facto means that key renegotiation and OTP are mutually exclusive, which will certainly be an interesting decision for business users.

[pbolduc]

Were you able to find a solution to this problem? I am experiencing the same problem here.

[franco]

For User Auth type OpenVPN servers there is a setting at the very bottom: Renegotiate time

The clients need to set this setting as well, if you have used the client exporter, you need to reexport after setting this setting to "0" for disabled.


Cheers,
Franco

[pbolduc]

Hi Franco,

Thanks for the reply, I must be blind because I have been in VPN -> Servers -> Edit Server for my (Remote Access (User Auth) Server and that setting does not exist at the very bottom. The last option i see is under Advanced Configuration - Verbosity level 1 (Default). What am I doing wrong?

Please see the attached screenshots showing the top of the page and the bottom of the page in that section. I also tried using Chrome & Firefox thinking perhaps there was a problem rendering this option.

[franco]

Hmm, it is only there for server modes "Remote Access (SSL/TLS + User Auth)" or "Remote Access (User Auth)". Otherwise 2FA/TOTP plays no role, because there is no user/password combo to ask.

If you are using a different server mode the problem may be elsewhere.

[pbolduc]

I am using Remote Access (User Auth) specifically and I am able to authenticate with the one time password using Google Authenticator. So authentication does work using my SSL VPN. My second thought was could I place this command "reneg-sec 0" in the Advanced Configuration Box at the bottom of the Server configuration page?

[franco]

Yes, reneg-sec is the same as the field. Is this not a 17.1 install? Which version? Must be a recent 16.7.x!

[pbolduc]

Okay i'll add that command into the advanced box and try it out. Yes this is a 16.7-i386 build on FreeBSD 10.3-Release-p5 and I must say I've implemented a lot of different features on this appliance already including Port Forwarding, IPsec VPNs and everything has been just amazingly great and I am using an Intel E1000 NIC in a Virtualized ESXi 6 Environment.

Note: I don't think I used the setup wizard to create the OpenVPN server. I just added a server manually. Perhaps that makes a difference whether or not the Renegotiate time option displays or not.

Just to follow up: Should the "Renegotiate time" option not appear under the OPENVPN Settings the command "reneg-sec 0" entered manually into the advanced box has corrected the problem. I have now been connected an hr 1/2 without a disconnect. Thanks for the assistance. For anyone just joining this conversation late both the VPN Client software and the router require this setting.

[minime]

Just for the record, I solved the problem by NOT using "keepalive". Now I have a stable connection.

[stefan21]

I assume that the mtu and mss settings on the WAN-interface have been set correct?

I struggled a long time with dropping and re-establishing connections on the tunnel. After setting the mtu on 1400 and the mss to 1300 for the WAN-interface, the tunnel is rock-stable. Of course the settings for the vpn-server and client have to match also.

stefan