Opened 3 years ago

Last modified 3 years ago

#1356 assigned Bug / Defect

State reported as RECONNECTING when trying second remote after first one fails

Reported by: ffes Owned by: plaisthos
Priority: major Milestone: release 2.6
Component: Generic / unclassified Version: OpenVPN 2.5.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

Ad suggested by @selvanair on GitHub? in https://github.com/OpenVPN/openvpn-gui/issues/177:

We have two remotes in our .ovpn config file. When the first fails (for instance when that server/line is down), it tries the second remote. The second remote connects, but it sets the state of the connection to "reconnecting" instead of "connecting".

@selvanair responded to that bug report:
If connecting to a second remote after failed attempts with another is reported as reconnecting, it looks like a bug in OpenVPN core.

This bug will have quite a big impact for our users when they need to connect via the second remote. The connect script of the openvpn-gui is not started as a result of this and the average user will think the connection has failed to be established.

Change History (3)

comment:1 Changed 3 years ago by Selva Nair

Summary: Connecting to second remoteState reported as RECONNECTING when trying second remote after first one fails

comment:2 Changed 3 years ago by Selva Nair

I can reproduce this using two remotes in the config with one bogus/inactive and other working. Here is a snippet of the logs showing the attempt on the first remote that fails:

2020-11-26 11:03:48 us=458221 UDP link local: (not bound)
2020-11-26 11:03:48 us=458221 UDP link remote: [AF_INET]xxx.xx.xxx.xxx:1195
2020-11-26 11:03:48 us=458221 MANAGEMENT: >STATE:1606406628,WAIT,,,,,,
2020-11-26 11:04:49 us=90494 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2020-11-26 11:04:49 us=90494 TLS Error: TLS handshake failed
2020-11-26 11:04:49 us=91506 TCP/UDP: Closing socket
2020-11-26 11:04:49 us=91506 SIGUSR1[soft,tls-error] received, process restarting
2020-11-26 11:04:49 us=91506 MANAGEMENT: >STATE:1606406689,RECONNECTING,tls-error,,,,,

The state change is reported as RECONNECTING although there was no successful previous connection. At this point the the second remote is tried and the connection succeeds.

OpenVPN-GUI interprets the state RECONNECTING as a restart of a previous successful connection, and, consequently, the <profile>_up.bat script is not executed when the connection finally succeeds.

I don't know enough to say whether this a "bug" in OpenVPN or the reported state change is correct and the GUI is wrongly relying on it to distinguish between initial connections and reconnections.

The documentation in management_notes.txt only says that the state "RECONNECTING" means a restart has occurred.

comment:3 Changed 3 years ago by Gert Döring

Milestone: release 2.6
Owner: set to plaisthos
Status: newassigned
Version: OpenVPN 2.5.0 (Community Ed)

I have seen your changes to openvpn-gui, and have no idea either on whether OpenVPN reporting is "right" or "wrong".

If anyone knows it might be plaisthos...

Note: See TracTickets for help on using tickets.