autologon, reverselogon, forward and incoming ... "Remote Service Platform (RSP)" functionality:
This functionality is used to access remote sites in a secure way for support, data transfer etc.:
- Access to remote sites can be controlled and logged centrally and decentrally.
- The users receive a list/menu, where he/she has access.
- Shortcuts can be managed centrally, e.g. for RDP or VNC.
When the central server of the Remote Service Platform is installed within the Intranet:
- There is no VPN client software necessary to access remote sites.
Access to remote web sites is possible from Intranet and Internet without special client software,
Hints to configure the authentication options can be found here.
See schemas with
- Clients.
- Remote web sites, see keyword REVPR.
Additional advantages:
In this example AppGW0 is the central server of the Remote Service Platform and
AppGW1 is the remote server located within the network where the computers schould be serviced via remote access.
There are no incoming connections to AppGW1 necessary because all connections are initiated by AppGW1.
Therefore this solution can be used with configurations where incoming connections to AppGW1 are not allowed per policy or the IP address of AppGW1 is dynamic.
Steps to initiate a connection via AppGW0 to AppGW1:
AppGW1 uses a routing entry with "autologon" as SourceIP (SSLTARGET, SSLCC and CONNECT are allowed) and initiates a session to AppGW0.
At AppGW0 the corresponding routing entry has "reverselogon" as GatewayIP2 (SSL and CCR are allowed).
This session is used as command channel to request new sessions by AppGW0 from AppGW1 to AppGW0.
At AppGW0 an incoming link with "forward" in GatewayIP2 requests a new session via open reverselogon session with matching RuleID in DestinationIP.
AppGW1 initiates a new session and maps it to a routing entry with "incoming" as SourceIP and matching RuleID in GatewayIP.
AppGW0 uses this session to communicate with AppGW1.
Here you can find help for the "autologon client" feature.
Here you can find details about "Processing of forward rules".
Here you can find details about "Management of remote computers via autologon".
Here you can find the Reverselogon Statistics.
Statistic data will be written into the file ReverselogonData.csv within the default directory and read at start of the program in order not to lose statistic data during restart and to have persistent statistics.
Keywords for autologon sessions:
RETRY:timespan ... time span in minutes to automatically restart autologon session in case of error. To specify seconds: timespan must end with "s".
DISABLED ... to disable autologon entries at table load, entries can be enabled via Listening entry within route table.
GENINC:destination ... For each RuleID specified in field GatewayIP a corresponding incoming routing entry will be generated (if RuleID is an IP port number).
......If destination is not specified it will be set to 127.0.0.1.
......Example: Keyword GENINC:127.0.0.10 in an autologon routing entry with RuleID 443 generates following new routing entry:
...... incoming;443; ; ;127.0.0.10;443; ; ;GEN-443
Remarks for autologon sessions:
If the reverselogon entry has no TTL specified: the TTL of the corresponding autologon entry will be used.
autologon sessions are automatically (re)started after loading the routing table (if not DISABLED).
autologon sessions send a keepalive message if actual time to live (TTL) of the session is lower then 5 minutes.
These keepalive messages update
- changes of incoming rules that are offered to the remote server (e.g. a rule becomes active or inactive according to a timer)
- changes of rules received from to remote server when acting in client mode
Keyword for reverselogon entries:
CHKCC ... when looking for reverselogon entries during forward processing, email names must be specified and must match (this is the default).
NOCHKCC ... when looking for reverselogon entries during forward processing, email names will not be checked.
MSG:messagegroups ... messagegroups is a list of groups (separated by | ) that contain text to be transmitted to the remote system.
- Further details can be found here.
Keywords for forward and incoming entries:
NOTIFYS:email ... list of email addresses, groups and * (separated by , ) to send notification when link starts (* will be replaced by eMail of connection).
NOTIFYT:email ... list of email addresses, groups and * (separated by , ) to send notification when link terminates (* will be replaced by eMail of connection).
Note: Mail notification must be configured.
Keywords for incoming entries (see also here):
CCRI:EmailAddresses ... same syntax as keyword CCR
ISSI:"issuer" ... optional, same syntax as keyword ISS
RuleIDs:
RuleID(s) are defined in routing entries and used to forward the connections:
autologon (field GatewayIP), incoming (field GatewayIP), reverselogon (field DestinationIP), forward (field DestinationIP) .
A rule is active only if it is defined on both sides (autologon and reverselogon). If the intersection of RuleIDs is empty, the autologon session terminates.
Special RuleIDs are:
client ... for autologon and reverselogon routing entries to signal the transmission of routing entries from the server (reverselogon) to the client (autologon).
mgmt ... for autologon and reverselogon routing entries to allow management of the remote ApplicGate instance. Details can be found here.
mqlg ... for autologon and reverselogon routing entries to allow sending of ApplicGate message queue status. Details can be found here.
updonly ... for reverselogon entries: Only update of the ApplicGate software is allowed via this routing entry.
Routing entries:
autologon: SourceIP=autologon, GatewayIP=list of RuleIDs (separated by | ), GatewayPort is not used
incoming: SourceIP=incoming, GatewayIP=RuleID, GatewayPort is optional
reverselogon: GatewayIP2=reverselogon, DestinationIP=list of RuleIDs (separated by | ) or * (any remote offered rules accepted), DestinationPort is not used
forward: GatewayIP2=forward, DestinationIP=RuleID (may be preceeded with requested email address at reverselogon entry, separated by :), DestinationPort is not used
...... At the end of RuleID a remote computer name (separated by %) may be specified e.g. mail@mydomain.com:R3%MYCOMPUTER
...... Then the connection will be established only to this computer, useful for failover configurations to allow direct addressing for e.g. status links to the remote Application Gateway.
...... Also a list of computers is supported, e.g mail@mydomain.com:R3%MYCOMP1|MYCOMP2|MYCOMP3
...... In this case the newest session of a computer in this list will be used.
RSP Examples:
-> First Example
-> Rule selection at AppGW0 dependent on the client certificate of the logged on AppGW
-> Addressing of incoming entries dependent on the email address of the remote user
Local forwarding Example:
-> Addressing of local incoming entries by forward entries
================================================================================================================================
First Example:
Example for Routing Table at AppGW0 ... central server of the Remote Service Platform:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
* ;1.2.3.4 ;777 ;reverselogon;R1|R2|R3 ; ;2018-10-20;SSL:srv.cer,CCR:lg1@x.com,NOCHKCC ;1.0;myComment;mike@x.com
* ;* ;1101 ;forward ;R1 ; ;2017-10-20; ;1.1; ;alice@x.com
* ;* ;1102 ;forward ;R2 ; ;2016-10-20; ;1.2; ;bob@x.com
* ;* ;1103 ;forward ;R3 ; ;2016-10-20;CONNECT:10.2.3.4:3389 ;1.3; ;joe@x.com
* ;1.2.3.5 ;888 ;reverselogon;* ; ;2016-10-20;SSL:srv.cer,CCR:lg2@x.com,NOCHKCC ;2.0; ;a@x.com
* ;* ;2101 ;forward ;R4 ; ;2017-10-20; ;2.1; ;alice@x.com
Example for Routing Table at AppGW1 ... logs on to AppGW0:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
autologon;R1|R2|R3 ; ;* ;1.2.3.4 ;777 ;2018-10-20;SSLTARGET:NoCheck,SSLCC:lg1x.cer ;1.0;myComment;mike@x.com
incoming ;R1 ; ;status ; ; ; ; ;1.1; ;alice@x.com
incoming ;R2 ; ;* ;10.2.3.2 ;3389 ;2016-10-20; ;1.2; ;bob@x.com
incoming ;R3 ; ;* ;ProxyFilter ; ;2016-10-20;PRX ;1.3; ;joe@x.com
Example for Routing Table at AppGW2 ... logs on to AppGW0:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
autologon;R4 ; ;* ;1.2.3.5 ;888 ;2018-10-20;SSLTARGET:NoCheck,SSLCC:lg2x.cer ;2.0;myComment;mike@x.com
incoming ;R4 ; ;manage ; ; ; ; ;2.1; ;alice@x.com
================================================================================================================================
Rule selection at AppGW0 dependent on the client certificate of the logged on AppGW:
Example for Routing Table at AppGW0 ... central server of the Remote Service Platform:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
* ;1.2.3.4 ;777 ;reverselogon;R1|R2 ; ;2018-10-20;SSL:server.cer,CCR:*@x.com ;1.0;myComment;mike@x.com
* ;1.2.3.5 ;80 ;forward ;lg@x.com:R1 ; ;2017-10-20; ;1.1; ;alice@x.com
* ;1.2.3.5 ;3389 ;forward ;lg@x.com:R2 ; ;2016-10-20;CONNECT:10.2.3.4:3389 ;1.2; ;bob@x.com
* ;1.2.3.6 ;80 ;forward ;lg2@x.com:R1%APPGWA ; ;2017-10-20; ;2.1a; ;alice@x.com
* ;1.2.3.6 ;81 ;forward ;lg2@x.com:R1%APPGWB ; ;2017-10-20; ;2.1b; ;alice@x.com
* ;1.2.3.8 ;3389 ;forward ;lg2@x.com:R2 ; ;2016-10-20;CONNECT:10.12.3.4:3389 ;2.2; ;bob@x.com
Example for Routing Table at APPGW1 ... logs on to AppGW0:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
autologon;R1|R2 ; ;* ;1.2.3.4 ;777 ;2018-10-20;SSLTARGET:NoCheck,SSLCC:lg1x.cer ;1.0;myComment;mike@x.com
incoming ;R1 ; ;manage ; ; ; ; ;1.1; ;alice@x.com
incoming ;R2 ; ;* ;* ;* ;2016-10-20;PRX ;1.2; ;bob@x.com
Example for Routing Table at APPGWA ... logs on to AppGW0:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
autologon;R1|R2 ; ;* ;1.2.3.4 ;777 ;2018-10-20;SSLTARGET:NoCheck,SSLCC:lg2x.cer ;1.0;myComment;mike@x.com
incoming ;R1 ; ;manage ; ; ; ; ;1.1; ;alice@x.com
incoming ;R2 ; ;* ;* ;* ;2016-10-20;PRX ;1.2; ;bob@x.com
Example for Routing Table at APPGWB ... logs on to AppGW0:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
autologon;R1|R2 ; ;* ;1.2.3.4 ;777 ;2018-10-20;SSLTARGET:NoCheck,SSLCC:lg2x.cer ;1.0;myComment;mike@x.com
incoming ;R1 ; ;manage ; ; ; ; ;1.1; ;alice@x.com
incoming ;R2 ; ;* ;* ;* ;2016-10-20;PRX ;1.2; ;bob@x.com
Note: The only difference between the config of AppGW1 and AppGWA (and AppGWB) is the client certificate within the SSLCC keyword.
AppGWA and AppGWB may have the same configuration because they are servicing the same site.
AppGW0 has separate rules for APPGWA and AppGWB with the computer name specified to allow direct addressing.
If rule with UID 2.2 is addressed at AppGW0, the newest autologon connection (AppGWA or AppGWB) will be chosen (hot standby configuration).
================================================================================================================================
Addressing of incoming entries dependent on the email address of the remote user:
Prerequisite: The user has to logon to AppGW0 and the email address of the user must be listed as SourceIP within the rule at AppGW0
or the CCR keyword is specified and the user presents a client certificate when connecting to AppGW0.
Then AppGW0 sends the email address to AppGW1 during link activation.
AppGW1 checks the email address if the CCRI keyword is defined at the "incoming" rule.
Also the issuer of the certificate will be checked if the ISS keyword is specified at the "incoming" rule.
Various "incoming" rules with the same GatewayIP (in that case RuleID) can be defined.
The first matching entry will be chosen.
Example for Routing Table at AppGW0... central server of the Remote Service Platform:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
* ;1.2.3.4 ;777 ;reverselogon;R1|R2 ; ;2018-10-20;SSL:srv.cer,CCR:lg@x.com,NOCHKCC ;1.0;myComment;mike@x.com
alice@x.com;* ;445 ;forward ;R1 ; ;2017-10-20;CONNECT:10.2.3.4:* ;1.1; ;alice@x.com
joe@x.com ;* ;3389 ;forward ;R1 ; ;2016-10-20;CONNECT:10.2.3.4:* ;1.2; ;joe@x.com
* ;* ;443 ;forward ;R2 ; ;2016-10-20;SSL:srv.cer,CCR:joe@x.com ;1.3; ;joe@x.com
Example for Routing Table at AppGW1 ... logs on to AppGW0:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
autologon;R1 ; ;* ;1.2.3.4 ;777 ;2018-10-20;SSLTARGET:NoCheck,SSLCC:lgx.cer ;1.0;myComment;mike@x.com
incoming ;R1 ; ;* ;ProxyFilter1 ; ;2016-10-20;PRX,CCRI:alice@x.com ;1.1; ;joe@x.com
incoming ;R1 ; ;* ;ProxyFilter2 ; ;2016-10-20;PRX,CCRI:joe@x.com ;1.2; ;joe@x.com
incoming ;R2 ; ;manage ; ; ;2016-10-20; CCRI:joe@x.com ;1.3; ;joe@x.com
Content of proxy filters (if any) in the example above:
ProxyFilter1: 10.2.3.4!445
ProxyFilter2: 10.2.3.4!3389
Now the Application Gateway AppGW1 at the destination has full control:
only alice@x.com may access shares at 10.2.3.4
only joe@x.com may access 10.2.3.4 via RDP
only joe@x.com may manage
================================================================================================================================
Addressing of local incoming entries by forward entries:
This feature allows addressing of different routing entries dependent on the certificate of the client.
Within the forwarding entry the requested RuleID must be preceeded by the string "local", keywords SSL and CCR must be specified.
Multiple incoming entries with the corresponding RuleID may be specified. The client certificate will be checked against keyword CCRI.
Example:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
* ;* ;443 ;forward ;local:R1 ; ;2017-10-20;SSL:myCert.cer,CCR:*@x.com ;1.1; ;alice@x.com
incoming ;R1 ; ;status ; ; ;2017-10-20;CCRI:abc@x.com ;1.2; ;alice@x.com
incoming ;R1 ; ;* ;10.2.3.2 ;* ;2016-10-20;CCRI:def@x.com ;1.3; ;bob@x.com
incoming ;R1 ; ;web ; ; ;2016-10-20; ;1.4;default ;joe@x.com
Client abc@x.com will see the status page, client def@x.com will be forwarded to 10.2.3.2, all other @x.com clients will see the local web page.
This works also with forwarding entries with OTPR specified:
Example:
SourceIP ;GatewayIP ;GatewayPort;GatewayIP2 ;DestinationIP;DestinationPort;Expiration;Type ;UID;Comment ;eMail
* ;* ;443 ;forward ;local:R1 ; ;2017-10-20;SSL:myCert.cer,OTPU:*@x.com,OTPR:otpdir,SENDOTP:processfile;1.1;;alice@x.com
incoming ;R1 ; ;status ; ; ;2017-10-20;CCRI:abc@x.com ;1.2; ;alice@x.com
incoming ;R1 ; ;* ;10.2.3.2 ;* ;2016-10-20;CCRI:def@x.com ;1.3; ;bob@x.com
incoming ;R1 ; ;web ; ; ;2016-10-20; ;1.4;default ;joe@x.com
In both configurations the incoming rule may have type PRX and even reverse proxy, e.g.
incoming ;R1 ; ;* ;X_Proxy ; ;* ;PRX ;1.x; ;
X_Proxy entries may forward to incoming rules by specifying host>local:rule
Remark:
If you look at the detailed status display of a link you may find the item "RtUID-history":
It shows all routing entries processed except the last one that is shown in item "RtUID".
================================================================================================================================
