For publishing HTTP/HTTPS servers, reverse proxy rules are the recommended publishing method.
Unlike DNAT rules, they offer the ability to:
-
Publish HTTP servers via HTTPS and vice versa.
-
Load-balance the requests to a web server farm.
-
Restrict the access to the published servers for certain useragents.
-
Substitute the domains and paths used by the published servers.
To publish a server using reverse proxy rules, follow these steps:
|
Task |
Description |
|---|---|
|
Step 1. Create a reverse proxy server. |
In the Global portal --> Reverse proxy servers section, click Add and create one or more web servers to be published. |
|
Step 2. (Optional) Create a balancing rule for the reverse proxy servers. |
If you need load balancing within a farm of published servers, go to the Network policies --> Load balancing section and create a reverse proxy load balancer. Use the reverse proxy servers created at the previous step. |
|
Step 3. Create a reverse proxy rule. |
In the Global portal --> Reverse proxy rules, create a rule that will set the conditions for publishing the servers or server farm. Important! Publishing rules are applied top to bottom in the rule list. Only the first rule for which all conditions are matched is triggered. |
|
Step 4. Allow the reverse proxy service in the zone from where access to the internal resources needs to be allowed. |
In the Network --> Zones section, allow the reverse proxy service for the zone from where access to the internal resources needs to be allowed (usually the Untrusted zone). |
To add a reverse proxy server, go to the Global portal --> Reverse proxy servers section, click Add, and fill in these fields:
|
Name |
Description |
|---|---|
|
Name |
The name of the published server. |
|
Description |
A description of the published server. |
|
Server address |
The IP address of the published server. |
|
Port |
The TCP port of the published server. |
|
HTTPS to server |
Specifies whether or not HTTPS access to the published server is required. |
|
Check SSL certificate |
Enables or disables validity checking for the SSL certificate installed on the published server. |
|
Keep original source IP address |
Keeps the original source IP address in the packets forwarded to the published server. If this is disabled, the source IP address is substituted with UserGate's IP address. |
To create a balancing rule for reverse proxy servers, go to the Network policies --> Load balancing section, select Add --> Add reverse proxy load balancer, and fill in these fields:
|
Name |
Description |
|---|---|
|
Enabled |
Enables or disables the rule. |
|
Name |
The name of the rule. |
|
Description |
A description of the rule. |
|
Reverse proxy servers |
The list of reverse proxy servers created at the previous step between which the load will be distributed. |
To create a reverse proxy rule, go to the Global portal --> Reverse proxy rules section, click Add, and fill in the relevant fields.
Note
The rules are applied top to bottom in their listing order. Only the first rule in which all conditions are matched is applied. This means that more specific rules must be placed higher in the list than more general ones. To change the order in which the rules will be applied, use the Up/Down and Top/Bottom buttons or drag and drop the rules with the mouse.
Note
The Negate checkbox changes the condition to the opposite, which corresponds to a Boolean NOT (negation).
|
Name |
Description |
|---|---|
|
Enabled |
Enables or disables the rule. |
|
Name |
The name of the rule. |
|
Description |
A description of the rule. |
|
Reverse proxy server |
The reverse proxy server or reverse proxy load balancer to which UserGate will forward the requests. |
|
Port |
The port on which UserGate will listen for incoming requests. |
|
Use HTTPS |
Enables HTTPS support. |
|
Certificate |
The certificate used to support HTTPS connections. |
|
Authenticate by certificate |
If enabled, the browser will be required to present a user certificate. To that end, the user certificate must be added to the UserGate's certificate list, assigned the User certificate role, and assigned to the corresponding UserGate user. For more details on user certificates, see the section Certificate Management. |
|
Source |
The zone, IP address lists, GeoIP address lists, or URL lists of the traffic source. The URL list must include only domain names. Every 5 minutes UserGate resolves domain names into IP addresses and stores the result in the internal cache for the DNS record's time-to-live (TTL). When the TTL expires, UserGate automatically updates the IP address value. Important! There is a limit on the number of GeoIPs that can be specified: the number cannot exceed 15. Important! Traffic processing performed with the following statements:
|
|
Users |
The list of users and groups to which this rule is applied. The Any, Unknown, and Known user types can be used. To apply rules to specific users or Known users, user identification needs to be configured. This tab is only available when HTTPS and certificate-based authorization is used. |
|
Destination |
One of the external IP addresses of the UserGate server, which is available from the Internet and is the destination for the external client traffic. Important! There is a limit on the number of GeoIPs that can be specified: the number cannot exceed 15. Important! Traffic processing performed with the following statements:
|
|
Useragent |
The user browser useragents for which this rule will be applied. |
|
Path rewrite |
Substitute a URL domain and/or path in the user request. For example, this allows requests at http://www.example.com/path1 to be converted into requests at http://www.example.loc/path2. Change from: the URL domain and/or path that needs to be substituted. Change to: the URL domain and/or path with which the original ones should be substituted. If a domain is specified in the Change from field, the rule will be only applied to the requests arriving at that specific domain. Thus, in this case, the domain will serve as a condition for triggering the rule. |