Since version HTML5 v7.49 the gateway supports back reverse proxy style even via proxy. What is the main difference to the usual reverse proxy style by /~~****?
Usually when ever browser navigates the gateway as example by link http://domain.com/~~srv1 it creates remote TCP connection to target server with provided IP/domain valid for /~~srv1 string. In that case the remote IP/domain must be accessible by that gateway. That means, if gateway is accessible from internet but the subserver doesn't share the same intranet range with that gateway then the subserver must be accessible from internet for gateway too, also both must have internet IPs to be visible to each other.
The new back-connection-reverse-proxy style mitigates that restriction. In the case above the subserver doesn't need to be directly visible to the gateway anymore, it is sufficient that the subserver can access the gateway directly. That works by establishing one control connection to gateway via secured line with special handshake exchanging session security keys.
From that moment on as soon anyone requests http://domain.com/~~srv1 link the gateway will send to subserver via already established control connection a small TCP connection request, so the subserver will create new TCP connection to gateway per this request with special one time only valid hash string and from that moment the gateway connection request on http://domain.com/~~srv1 will continue on that new TCP connection so as if gateway has created this TCP connection.
To use it the setup must be done not only on gateway but on targeted subserver too.
The gateway uses almost the same style as for usual load balancing.
----------GATEWAY-PART-->--webserver\balance.
/~~srvBACK=mypassword1234#:1;
accepts any IP that tries to connect to gateway, as password must be used mypassword1234
The hash # on end of password is mandatory and used as indicator to distinguish it from other balance.bin entries with IP/domains
The port is not anymore accounted, it must be just any positive value, even 1 is ok,
with the same success you could use char * like so> /~~srvBACK=mypassword1234#:*; instead numeric value.
or
/~~srvBACK=mypassword1234#:*
accepts only connection that was established from IP 51.254.22.85, only one IP entry allowed, here is leading char * mandatory
or
/~~srvBACK=mypassword1234#:*
accepts only connection from IP that begins with 51.254., it could cover potential IP range but only one IP entry allowed, leading char * is mandatory
or
/~~srvBACK=mypassword1234#:*de
accepts resolved IP for demo.mydyndns.net, that means, when new connection on gateway for /~~srvBACK was established
the gateway firstly resolves the domain (in example demo.mydyndns.net) to IP and compares it to IP that tried to connect to the gateway.
That can be used as additional security level accepting home subservers registered on dynamic DNS services, leading char * is mandatory
or
SSL /~~srvBACK=mypassword1234#:*;
SSL /~~srvBACK=mypassword1234#:1;
accepts any IP that tries to connect to gateway, as password must be used mypassword1234 (remember # hash is mandatory on end)
but additionally the connection gets encrypted by SSL for HTTP requests only.
The setting like /~~srvBACK=mypassword1234#:
----------SUBSERVER-PART-->--webserver\
/~~srvBACK=mypassword1234#demo
Notice here, subserver settings part uses another file name than gateway part!
The subserver that should be accessible via gateway by /~~srvBACK will register itself on gateway with main controlling connection.
Only one control connection is allowed to the same gateway for specific /~~srvBACK string, if any one else will try to renew the main control connection even with a valid password, it will be dropped. The main control connection sends each 20 seconds alive packet, so in case if connection was not responsive for at least 1 minute then such connection will be marked as invalid to be closed and so establishing of the next control connection will be allowed. Such a situation may happen if the provider blocks TCP connection for any reason but doesn't send close command, this may happen obviously.
Unlike usual reverse proxy style this kind of connection is not allowed to be hot-refreshed, so to accept new back-balance settings the subserver must be restarted. The gateway is allowed to hot-refresh the settings but the already established control connection won't be dropped and will continue with old settings until being dropped or after gateways restart.
It is not recommended to replace this feature with already used load balancing scenario but in the case if a company wants to allow their users to make accessible their home PCs via companies gateway then this feature is perfectly meeting such needs.
As example
https://demo.tsplus.net/~~
or
https://demo.tsplus.net/~~
etc.
in such case you could travel in the world and be able to access your Home PC via https://demo.yourserver.net/~~myHomePC even when your own PC is not available from being accessed from the internet directly.
As mentioned, it supports not only clean TCP connection but even HTTPS proxy with CONNECT style for back-reverse-proxy mode by backbalance.bin with NTLM and Basic authentication.
Now not only regular home users can bind their intranet home PCs into standalone gateway, now corporate clients behind proxy
as example with NTLM authentication can make their internal servers available on remote gateway accessible via /~~** reverse proxy style. Moreover it supports cascade proxy connection with authentication on each cascade proxy server.
To make it working add as last line on SUBSERVER-PART in webserver\backbalance.bin following (not balance.bin!!!)
/~~srv1=jw_initialpassword#309
this will connect to 3090.ip-47-197-143.eu:443 via proxy 192.168.10.11:808 by using NTLM logon: \myuser1
or
/~~srv1=jw_initialpassword#309
same like before but additionally next cascade proxy server used 192.168.12.12:808
The logon supports no-authentication just by providing proxy string -> 192.168.10.11:808;
the NTLM logon usage gets enforced by slash char \ inside login part, no slash char means Basic authentication like
-> myuser2:[email protected]:
If customer uses NTLM logon with domain part, the slash will remain inside login part like on example
/~~srv1=jw_initialpassword#309
but by no domain usage with NTLM auth leading slash char on login part is mandatory anyway
-> \myuser2:[email protected]:
else as Basic auth handled.