Zero-config HTTP relay server

Question

I develop a desktop product (C#) that has a built-in Web server (ServiceStack) that can be used for remote management of the database - I will refer to this as the Internal Server. Many users want to access the Internal Server outside their network but the support burden on my side of getting them to configure firewalls and port forwarding is too high. Also, dynamic IP addresses can also be an issue.

I am trying to come up with a way to create a zero-config service where a user can connect to an external server I host which is able to relay the requests to the Internal Server without having to configure anything on the Internal Service. It should 'just work' from the user's perspective.

This would be akin to the way TeamViewer/AnyDesk/etc works where the user can just log in and 'connect' to their computer without having to configure firewalls.

I have developed a proof-of-concept based on the Sequence Diagram below. It works, but the performance vs the direct connection is very slow.

How could this be better achieved and are there any solutions that have solved this problem out-of-the-box?

The key challenge shown in the diagram below is that the Public Relay Server should not initiate a direct connection to the Internal Server.

Answer 1

Possible thoughts for improvement:

• If possible, use HTTP/2 between the relay and the internal server (ideally just everywhere though). This will let you take advantage of HTTP/2 Server Push functionality instead of needing to poll or leave a hanging request from the internal server waiting for a new external request, as well as providing a number of other potential performance improvements.
• Make the communications between the client system and the relay/internal server asynchronous. So, the client sends a regular request to relay/internal server, gets a response back that it was accepted, and then waits for a secondary response from the server (either via HTTP/2 Server Push functionality, or some other push notification mechanism). This lets you give better feedback to the user that the request is actually being processed, which will help things feel faster even if it doesn't actually improve performance.
• Preemptively send the request from the relay to the internal server when you're notifying the internal server about the request. This will eliminate a full round trip between the relay and the internal server, which should significantly speed things up.
• If implementing the above point, use the same async communications model I mentioned further up between the relay and the internal server.
• Look into the possibility of using ICE (or something similar) to set up a direct connection between the client and the internal server whenever possible. Your biggest performance bottleneck here is really the relay server itself, if you can set things up so some (or possibly all) of the users can avoid needing to talk to it other than during the connection setup, you should see a pretty big performance improvement.