FEATURE: Server availability

[x0r2d2]

Hey UH-VPN team,

Is it possible to show if server available or not from our end?

For example, if server get blocked, application will show RED light (or just word "DOWN") near to server name.

Will be useful if application can show ping value.

Thanks.

[AnthonyWharton]

I like this idea, from a UI perspective this could be integrated into a system similar to the coloured dots for profile availability.

However, whilst availability and ping should be possible, knowing whether or not a connection will be distrupted could be a little bit tricky. I imagine in lots of cases where internet connections are censored, servers may advertise themselves as being up successfully but then fail to make a connection - or make a successful handshake and then fail to maintain an active tunnel.

Having a server report itself as up, but then have a distrupted connection would in my opinion probably be a more frustrating user experience, not to mention that it could be seen as a broken feature which we wouldn't want to implement! I do like the idea though so I'll have a think about it!

[x0r2d2]

@AnthonyWharton

The server up value = IP address available (not blocked) from our side. If IP available, the application will show ping value.

[AnthonyWharton]

We've had a pretty long discussion about this idea today internally, talking about different means for having functionality that would support this. For the time being we don't think there's a quick way to implement this in a way that will consistently work for all our users and clients.

• The IP being accessible is not an accurate enough way to test that the server is reachable, as other more advanced systems may block connections mid session. We might look into engineering some client-side connection testing facilities, or an addition monitoring service in future but for now this is out of scope.
• Showing a ping is problematic as lots of users run UH VPN behind NAT, and pings may not even reach the server.
• We could look at adding some available metrics to the 2802 management port with the uh-vpn-server package, but this is an optional feature for server hosts and thus many servers may report themselves as down when they are not down.

We'll continue looking into this as I think this would bring a great QOL improvment to our users. For the time being however, we are focussed on on pushing out the DPI evasion features to all our clients, along with some other updates to bring Windows inline with macOS.

As an aside, there are some tools out there for providing remote server management with protocols such as SNMP. If this is simply for administration purposes this might be a good alternative to look at in the meantime.

[jwsi]

Hey @hybtoy,

Thanks for the feature request!

My main concern is the fact that quite a few UH VPN servers may be behind NAT with public facing gateways that don't respond to ICMP requests. This could falsely report a server as down. Furthermore, even if these gateways do respond to ICMP echos, it doesn't necessarily confirm availability of the server.

Potential proposal:

• First and foremost I think this needs to be an opt-in feature. It makes sense to enable/disable this functionality on the group settings page. Then admins have the flexibility on whether their users can view server availability to avoid false negatives.

• I think a custom protocol is needed here that is more powerful than the ping/ICMP option. Imagine the case where a server runs and responds to pings, but no uh-vpn-server instances are running. Therefore, it makes sense to add a custom responder on the TCP 2802 port that is used for management purposes. One that reports up/down for a given server ID. That way the apps can assert whether a server is indeed running and ready to accept UH VPN connections in real time which is more powerful than ICMP and provides granularity between multiple VPN servers running on the same machine.

I think once the DPI features are finalised and integrated and when our bug fixes for macOS/iOS are released we can flesh this out in more detail.

Thanks again, James.

[sunny75016]

Instead of (or in addition to) the red and green dots, it could make sense to indicate the time in seconds of the last data transfer. This should address the false connection frustration Anthony mentions. I do not trust the ping result. Just a suggestion to consider. Thanks.

[AnthonyWharton]

Hi @sunny75016,

Could you elaborate on what you mean? Last data transfer between what - the UH VPN API and the server, the device and the server, something else?

Thanks, Anthony

[sunny75016]

I meant the connection between my private DO instance running UH-vpn and my devices.

[AnthonyWharton]

We could have a "Last Connected" feature... however there are no other transfers between the device and server directly, only the VPN connection itself. I think that would likely just add more clutter to the UI, however if people can make a strong case for it I can look into that after finishing working on the release for #7.