Keyword REVPR ... REVersePRoxy
This keyword is valid only for status and manage rules.
Motivation for this function is to have access to http(s) shortcuts within the UID field using the current session.
Example with keyword REVPR specified at a manage or status rule:
- The Application Gateway is accessed via manage link https://194.99.88.1:88
- There is a shortcut in a rule with following configuration:
-- Gateway IP: 10.10.0.2
-- Gateway port: 90
-- Shortcut: http://*/status
- The resulting link of the shortcut is:
-- https://194.99.88.1:88/_10.10.0.2:90/status
This means that the current session is used and the Application Gateway acts as a proxy.
In the example above the address 10.10.0.2 needs not to be directly reachable by the requestor.
If the keyword REVPR is not specified the resulting link would be:
- http://10.10.0.2:90/status
Access Control:
If SourceIP of the target rule is not *: The email address (requested via keyword CCR) of the logged on session must match.
Error messages:
If for any reason no matching rule could be found (invalid IP address, invalid email address) an error message will be returned:
- The builtin template for the error message can be seen here.
- To use a custom template: Store the file ReverseProxyError.htm into the default directory.
- The string %Error% will be replaced by a detailed error message.
Any RDRF keyword in the target rule is supported also.
Remark:
The above schema works perfectly if the target web has only relative addresses, e.g. as implemented within the Application Gateway.
If the target web uses absolute addresses, the http attribute Referer will be used to find the correct link.
Additionally the command uidrpr can be used to show a list of all routing entries with http(s) shortcuts (and reverse proxy links).
Note: A client certificate must be presented for access control!
Example:SourceIP;GatewayIP;GatewayPort;GatewayIP2;DestinationIP;DestinationPort;Expiration;Type ;UID ;Comment;eMail
* ;2.2.2.2 ;188 ;status ; ; ;* ;SSL:server.cer,CCR:x@xx.com,REVPR; ; ;
x@xx.com;127.0.0.1;180 ;* ;1.1.1.1 ;80 ; ;UIDN:"Test!x@xx.com" ;1.1~http://*/;MyTest ;y@xx.com
Now the url https://2.2.2.2:188/uidrpr returns a page like this:UIDname UID Shortcut Comment
Test 1.1 http://*/ MyTest
where http://*/ resolves to https://2.2.2.2:188/_127.0.0.1:180/
If the link to the destination requires TLS, the Application Gateway will automatically initiate a TLS session:
Example:SourceIP;GatewayIP;GatewayPort;GatewayIP2;DestinationIP;DestinationPort;Expiration;Type ;UID ;Comment ;eMail
* ;2.2.2.2 ;188 ;status ; ; ;* ;SSL:server.cer,CCR:x@xx.com,REVPR; ; ;
x@xx.com;2.2.2.1 ;443 ;2.2.2.3 ;1.1.1.1 ;443 ; ;UIDN:"Test!x@xx.com" ;1.1~https://*/;MyTest ;y@xx.com
Now the url https://2.2.2.2:188/uidrpr returns a page like this:UIDname UID Shortcut Comment
Test 1.1 https://*/ MyTest
where https://*/ resolves to https://2.2.2.2:188/_2.2.2.1:443/
As there is a TLS session from the client to the Application Gateway (2.2.2.2) already, the Application Gateway initiates a TLS session automatically (2.2.2.3 to 1.1.1.1)
At the second rule a client certificate can be specified using keyword SSLCC if required by the destination (1.1.1.1).
If the second rule can be addressed directly (via https://2.2.2.1 ) the TLS session will go directly from the client to the destination (1.1.1.1)
As x@xx.com is specified as SourceIP the client must be logged on with the appropriate certificate.
