Reverse Proxy

Introduction

About this Document

This document is intended for technical experts and system administrators. It explains the security concepts and configuration of the AXS Guard reverse proxy feature to secure HTTP(S), FTP and RDG applications.

Examples used in this Guide

All setups and configuration examples in this guide are executed as an advanced administrator. Some options are not available if you log in as a full administrator or a user with lower access privileges.

As software development and documentation are ongoing processes, the screenshots shown in this guide may slightly deviate from the current user interface.

Introduction to the Reverse Proxy

WAF Functionalities

The AXS Guard Reverse Proxy improves performance, scalability, and security by offloading tasks from the backend servers.

AXS Guard combines the functionality of a Web Application Firewall (WAF) with a powerful reverse proxy. This WAF-enabled reverse proxy serves as a gateway for internet client requests, ensuring secure communications by authenticating clients and directing their requests to the appropriate LAN server.

By acting as a shield, the WAF prevents potential attacks and exploits on the LAN server. The integrated WAF component provides advanced security features like request filtering, RFC compliance, strong authentication and brute-force attack prevention.

Moreover, the WAF-enabled reverse proxy offloads SSL processing from the application servers, resulting in improved performance and scalability. Overall, it provides secure access to internal resources, safeguards sensitive data, and enhances network security.

Reverse Proxy Concept

Using a Reverse Proxy vs. Port Fowarding

Port forwarding is to be avoided due to its inherent security risks. With port forwarding, application servers are directly accessible from the Internet which means their potential vulnerabilities can be exploited more easily. If an application server is compromised, your private data and secure network may be at risk.

Using a Reverse Proxy vs. a DMZ

Another method to allow access to applications and web servers is through a DMZ. A DMZ solves the problem of access to private data in the secure LAN, for instance access to a database server. However, DMZ servers are directly accessible from the Internet and therefore susceptible to attacks. For this reason, the AXS Guard firewall does not allow connections from the DMZ to the secure LAN by default. Advanced firewall rules are required.

Network Zones

From / To	to SEC	to DMZ	to INT
From SEC	configuration allowed	configuration allowed	configuration allowed
From DMZ	use advanced firewall rules	configuration allowed	configuration allowed
From INT	use advanced firewall rules	configuration allowed (dmzf)	use advanced firewall rules

Reverse Proxy Features

Supported Protocols

Type	Description
TCP/IP protocols	HTTP/1.0, HTTP/1.1, HTTP/2.0 and FTP
Application protocols	WebSocket, RPC over HTTP, MAPI over HTTP, EWS and RDP (via remote desktop gateway)

Info

For applications using other protocols, a VPN connection is recommended.

RFC Compliance

The reverse proxy is designed to filter potentially dangerous requests which could cripple your application server.

The AXS Guard appliance protects your application servers by only allowing a specific set of characters in browser requests, a.k.a. character escaping. The character set is defined in RFC 2396.

For example, spaces in URLs are converted to %20. Note that query strings are not escaped. Query strings are the characters which follow an interrogation mark ? in a URL, e.g. http://www.imdb.com/find?s=all&q=the+great+escape&x=0&y=0.

The AXS Guard reverse proxy also protects your application against buffer overflows. Not all applications can handle extensively long URLs. Requests containing such URLs may result in unwanted program behavior or can even crash your application server.

Request Filtering

The AXS Guard Reverse Proxy works at the URL level and inspects HTTP traffic to ensure it is RFC-compliant. It can also modify the contents of URLs, a.k.a. URL replacement.

Administrators can specify restrictions on top of the enforced RFC standards to block URLs or parts thereof through the use of regular expressions (PCRE).

Exceptions can be configured to allow specific requests which would otherwise match a blocked request. The default configuration of the AXS Guard Reverse Proxy server is optimized for applications running on Microsoft IIS, such as the Outlook Web Access server.

Example: Combining allowed and denied requests

Assume you want all URLs containing the word scripts to be blocked, e.g. http://www.example.com/scripts/adduser.php, while a specific URL containing the word scripts should be allowed, e.g. http://www.example.com/scripts/subscribe-infosession.php. The AXS Guard reverse proxy allows you to specify an exception for /scripts/subscribe-infosession.php.

Denied Requests

Option

Description

Deny Following Requests

Requests for URLs that match any of the specified patterns will be blocked. You can use PCRE to define patterns:

An asterisk * is used to specify repetition, indicating zero or more occurrences of the preceding element.
The dot . is a special character in PCRE that matches any single character except for a newline.
A question mark ? is used to designate any character, e.g. the string www.?unet.com matches http://www.aunet.com, http://www.bunet.com, http://www.cunet.com, etc.
A caret ^ designates the beginning of the server portion in a URL, e.g. ^slashdot.org matches http://slashdot.org/, http://slashdot.org/login.pl, but not http://mail.slashdot.org/.
$ designates the end of a website, e.g. vrt.be/teletekst$ matches http://www.vrt.be/teletekst, but not http://www.vrt.be/teletekst/nieuws.

Allow Following Requests

Must be used to overrule denied requests. Requests for URLs that match any of the specified patterns will be allowed. Use the same regex syntax as explained above.

Understanding the .* Pattern in PCRE: Matching Any Character Zero or More Times

When .* are used together, it forms a pattern that can match any sequence of characters (except for newlines) of any length. It will greedily match as many characters as possible.

Suppose we have the following string: Hello, World!. The PCRE pattern H.*o will match the entire string Hello.

The H matches the letter H.
The .* matches any number of characters, in this case, it matches ello, W.
The o matches the letter o.

Therefore, the match is "Hello".

It's important to note that .* can sometimes lead to unintended or inefficient matching, as it can match across multiple parts of a string. In such cases, it's advisable to use more specific patterns if possible to avoid unexpected matches.

Allowed Requests

URL restrictions can be overruled by adding a full URL entry or a part thereof, and by using the same regex syntax as explained in the denied requests section.

Base URL Protection

Base URL protection is a method to protect your web server against unauthorized access. This is achieved by restricting access to a defined set of URLs. Check the documentation of your application server to verify which URLs it publishes by default and which are the ones that need special protection.

A web server such as www.vasco.com has several URLs:

www.vasco.com/public
www.vasco.com/private
www.vasco.com/support

By adding /public/ as a base URL, only www.vasco.com/public is accessible to the public. Other requests are redirected to the allowed URL, e.g. an incoming request for www.vasco.com/private would be redirected to www.vasco.com/public.

Example: Microsoft OWA 2003

When running a Microsoft OWA 2003 server, only the following URLs should be accessible:

/exchange/
/exchweb/
/public/

Info

Include a forward slash / before and after each entry.
If multiple base URLs are defined, any unauthorized request is automatically redirected to the base URL on top of the list. In our example, that would be /exchange/

Access Control

IP address restrictions play a crucial role in safeguarding your web applications against undesirable visitors. By implementing these restrictions, system administrators can selectively grant access based on specific IP addresses. This valuable feature effectively thwarts unwanted visitors and shields your applications from automated cyberattacks.

When enforcing access restrictions for IP ranges, it is essential to utilize the CIDR notation, such as 192.0.2.0/24. Without defined restrictions, connections originating from any IP address will be permitted by default, unless alternative configurations are specified within the AXS Guard firewall.

By defining IP address restrictions, you can confine connections solely to the designated IP addresses or ranges. Consequently, any connections originating from other IP addresses will be promptly denied.

Predefined Applications

The AXS Guard Reverse Proxy server allows you to choose from a list of preconfigured applications.

When you choose a preconfigured application, the correct configuration settings are automatically applied, e.g. the base URLs, RFC compliance checks, authentication URLs, NTLM suppression, etc.

Additionally, some automatic redirects are also activated depending on the selected application.

Application	Description
Unlisted application	Select this option if you don’t know the specifics of the application server or if you wish to enforce authentication for a basic web server or an application which does not provide its own authentication.
Citrix 3	Citrix Metaframe 3 allows you to run applications you have at work from anywhere in the world. For detailed information about Citrix products, visit: http://www.citrix.com
Citrix 4	Citrix Metaframe 4 allows you to run applications you have at work from anywhere in the world. For detailed information about Citrix products, visit: http://www.citrix.com
Citrix Access 4	Application server for Citrix Access Gateway, Version 4.0. For detailed information about Citrix products, visit: http://www.citrix.com
Microsoft CRM	Microsoft Dynamics CRM is a customer relationship management software package developed by Microsoft.
Citrix NetScaler	Citrix NetScaler is an all-in-one web application delivery controller (ADC).
OWA 2013	Same as above, but version 2013. Also use this application for RPC over HTTPS, MAPI and EWS. Two authentication types are available: Form-based authentication Basic authentication Note that basic authentication is required for MAPI and EWS services, as NTLM is suppressed by default by the reverse proxy. See the official Microsoft documentation for additional information about how to configure your Exchange server for basic authentication.
OWA 2016	Same as above, but version 2016. Also use this application for RPC over HTTPS, MAPI and EWS. Two authentication types are available: Form-based authentication Basic authentication Note that basic authentication is required for MAPI and EWS services, as NTLM is suppressed by default by the reverse proxy. See the official Microsoft documentation for additional information about how to configure your Exchange server for basic authentication.
OWA 2019	Same as above, but version 2019. Also use this application for RPC over HTTPS, MAPI and EWS. Two authentication types are available: Form-based authentication Basic authentication Note that basic authentication is required for MAPI and EWS services, as NTLM is suppressed by default by the reverse proxy. See the official Microsoft documentation for additional information about how to configure your Exchange server for basic authentication.
XenApp 5	Citrix XenApp is a Windows application delivery system that manages applications in a datacenter and delivers them as an on-demand service to users anywhere using any device. For detailed information about Citrix products, visit: http://www.citrix.com
XenApp 7	Citrix XenApp is a Windows application delivery system that manages applications in a datacenter and delivers them as an on-demand service to users anywhere using any device. For detailed information about Citrix products, visit: http://www.citrix.com
Zimbra	Zimbra Collaboration Server.

Custom Applications

The AXS Guard appliance offers a set of predefined applications for ease of administration.

However, advanced administrators can also define and configure their own, custom applications. Once a custom application has been added, it will appear as a selectable application under HTTP(S) > Server.

Please note that this option is intended for advanced administrators with an extensive knowledge of HTTP. Contact support@axsguard.com if you wish to permanently add an application that does not appear in the list of predefined applications or if you are experiencing configuration difficulties.

Single Point of Access

Virtual Hosts

The term Virtual Host refers to the practice of running more than one web site or application, such as company1.example.com and company2.example.com on a single machine.

The AXS Guard Reverse Proxy server is the single point of Internet access towards your applications in the secure LAN; you want to respond differently for company1.example.com and company2.example.com. The Reverse Proxy will select the correct application based on the URL which is entered by users on the Internet.

Multiple applications with different hostnames can be made available to Internet users, while only a single public IP address is needed on port 443 or 80. It is advised to use multiple hostnames rather than multiple ports, as ports which deviate from the RFC standards (80 and 443) may not be allowed by intermediate Internet firewalls or routers and may be confusing to end users. Hostnames are also easier to remember than port numbers. The use of non-standard ports requires users to specify a port number after the URL, e.g. http://www.companyname.com:8080.

Each reverse proxy entry must have a unique IP address, port and hostname. Multiple hostnames (FQDNs) can be specified for a single application.

Reverse Proxy as a Single Point of Access

Catch-All Entry for Unmatched Virtual Hosts

Assume you have 3 active reverse proxy entries pointing to the public IP address 62.58.227.146.

External hostname: first.yourdomain.com > External IP: 62.58.227.146 > Internal IP: 192.168.0.2
External hostname: second.yourdomain.com > External IP: 62.58.227.146 > Internal IP: 192.168.0.3
External hostname: third.yourdomain.com > External IP: 62.58.227.146 > Internal IP: 192.168.0.4

Assume there is also a DNS record dns.random.net somewhere on the Internet which is pointing to 62.58.227.146. This DNS record is out of your control, i.e. created by mistake or even intentionally.

If a user on the Internet goes to dns.random.net or 62.58.227.146, (s)he will end up at first.yourdomain.com, i.e. the first active entry in your reverse proxy list. To prevent this behavior, we recommend that system administrators create a "catch-all" reverse proxy entry, without an external hostname. The entry should point to an internal server with an "Unauthorized" or "Domain not found" page.

Examples

Example 1: One reverse proxy entry using port 443

In this scenario, it is recommended to leave the hostname field empty. This way, all names resolving to the specified IP address will be allowed by the Reverse Proxy. If a hostname is entered, only requests matching the entered FQDN will be allowed by the AXS Guard Reverse Proxy Server.

Info

If a hostname is specified, you cannot use the public IP address in the browser’s URL field. Both the hostname and IP address must be added if needed.

Example 2: One public IP address with multiple reverse proxy entries using port 443

The IP address and port number are predefined. This means only the hostname can be used to point to the correct server in the secure LAN. A server with the following hostname intranet.yourdomain.com and AXS Guard authentication can be used to connect to the intranet webserver. Another host, e.g. owa.yourdomain.com, can be added to connect to your corporate MS Outlook Web Access server.

A third Reverse Proxy entry can be added for your company website. In this case you could add www.yourdomain.com as a hostname or you can choose not to specify a hostname at all.

In the first case, all non-matching FQDNs resolving to the Reverse Proxy’s IP are blocked as a security precaution.
In the second case, any FQDN which resolves to this IP address provides a connection to the company website.

HTTP and SSL

Introduction

An HTTPS connection is a secured HTTP connection. All data in the connection is encrypted using the Secure Sockets Layer (SSL) protocol (illustrated below). SSL is based on the public/private key (PKI) encryption model. The public key is published via a digital certificate stored on the secure web server.

SSL Offloading

SSL offloading relieves an application server of the processing burden of encrypting and/or decrypting traffic sent via SSL, the security protocol that is implemented in every Web browser. The processing can be offloaded to the AXS Guard, which is designed to perform SSL termination.

Enabling HTTPS for external connections is therefore strongly encouraged, as all data travels over the insecure Internet. SSL can be enabled separately for each reverse proxy entry.

The AXS Guard is capable of generating and signing certificates and supports the integration of trusted (CA) SSL certificates. The latter are imported via the AXS Guard web-based administrator tool. Note that only PKCS#12 and PEM certificates are supported. See the PKI manual for more information about managing certificates on the AXS Guard appliance.

SSL Offloading Concept

SSL for Internal Connections

Using HTTPS for communications between the AXS Guard Reverse Proxy and the application server(s) in the secure LAN is not recommended, as this produces encryption overhead. However, some applications only support HTTPS. For these servers it is more convenient to allow HTTPS, rather than modifying their configuration.

Important

You must use a secure connection towards the AXS Guard if the application only supports TLS or SSL.

Digital Certificates

A digital certificate is a computer file containing information which uniquely identifies its owner. The information consists of the owner’s public key, the expiration date of the certificate, the name of the Certificate Authority (CA), a unique name (host name), the signature of the CA , and other descriptive data. Certificates are encoded by the CA’s private key and can be verified with the CA’s public key. Any unauthorised changes to the certificate file generate a warning message in the client’s browser.

Self-Signed Certificates

A company may choose to create and sign its own certificate. This means the company acts as a CA and signs its own certificate. When you connect to a website with a self-signed certificate, a warning message similar to the image below appears.

Example of a Self-Signed Certificate Warning

Certificates Signed by a Trusted CA

Rather than signing their own certificate, companies may choose to purchase a certificate from a trusted known CA. A trusted CA is an independent network entity, responsible for the issuance and management of digital certificates. When you connect to a website that has a certificate signed by a trusted CA, your browser will not generate a warning message.

Domain Name Mismatch

The warning message Domain Name Mismatch occurs when the FQDN entered in the browser’s URL field does not match the host name used in the server certificate. This is to inform users that the contacted site may not be the actual intended site (man-in-the-middle attack).

The same message appears when a site changes its name (FQDN) without purchasing a new certificate that includes the changed name or when entering the server’s public IP address in the browser’s URL field, e.g. https://127.0.0.1, rather than the FQDN.

Example of a Domain Name Mismatch Warning

Important

If you change the Certificate Connection Name in an existing Reverse Proxy entry, you must use a new certificate with the correct host name.

Authentication

Overview of Supported Methods

Credential replacement Session management Basic authentication Form-based authentication Push notifications

The AXS Guard appliance offers a variety of authentication methods. Once a method has been selected, it applies to all reverse proxy entries. Detailed information about AXS Guard authentication methods is available in the AXS Guard Authentication How To, which is accessible via the Documentation button.

The following authentication methods are supported by the AXS Guard reverse proxy:

DIGIPASS and OATH tokens, which generate secure, one-time passwords.
Cronto Mobile App with push notifications.
Directory Service password (LDAP authentication).
RADIUS authentication.
Password authentication.
Combinations of the methods above.

The following authentication types are supported by the reverse proxy:

No authentication: In this case, the AXS Guard reverse proxy only filters incoming requests and ensures that these are RFC-compliant; authentication is provided by the application server if available.
Basic authentication: An authentication popup is presented to the user. The AXS Guard response includes a WWW-Authenticate header, indicating it expects basic authentication. DIGIPASS authentication is strongly recommended with basic authentication, as the password is sent over the wire in Base64 encoding, which can easily be converted to plain text.
Credential replacement: This type of authentication requires form-based authentication on the application server. The AXS Guard reverse proxy retrieves the application server’s login page, e.g. the Outlook Web Access login page, and presents it to the client. The client logs in using an AXS Guard password, e.g. a one-time password generated by a DIGIPASS token, which is intercepted and replaced with the user’s application credentials. The application password is securely stored in the user’s AXS Guard profile manually or via password auto-learning. This method allows you to enforce strong authentication for your applications while providing a single sign-on experience to the user.
Session management: Users are invited to log in via the configured AXS Guard login page. If the login is successful, a session cookie will be created and the user will be redirected to the configured application. This method allows you to enforce strong authentication while providing a single sign-on experience to the user.
Session management with credential replacement: Combines the features of credential replacement with session management, i.e. provides a single sign-on experience with a custom login page.

Strong Authentication with Push Notifications

The Cronto Mobile App leverages the widespread adoption of smartphones and provides an easy-to-use, portable transaction authentication solution for web applications.

The user experience is straightforward: users simply have to point their mobile phone camera at the screen, and all transaction details appear on the phone ready for verification.

The Cronto App is customized to for each deployment to meet the client’s branding and other requirements and is delivered to end users via application stores. Contact sales@axsguard.com for additional information.

Push Notifications Concept

Basic Authentication

Basic authentication is a method which enables users to provide their credentials through a pop-up window:

The AXS Guard prompts for user credentials when a web page is requested. No requests are forwarded to the application server as long as the requesting user is not successfully authenticated with the AXS Guard.

AXS Guard Basic Authentication

Important

2FA is strongly recommended with basic authentication, as passwords are transmitted in Base64 encoding, which can be easily converted to plain text.

Because of its concept and design, basic authentication cannot be implemented simultaneously on the application server and the AXS Guard. For example, enabling basic authentication on a Microsoft Outlook Web Access 2003 server and the AXS Guard is technically impossible. Use credential replacement if authentication is required on the AXS Guard and the application server.

Credential Replacement

Concept and Requirements

Credential replacement Form-based authentication Application server credentials

Credential replacement can only be used if the application server uses form-based authentication, i.e. the user credentials are entered in a form which is incorporated in the web page, rather than a pop-up window.

Form-based authentication

Users log in via the login page of the application server, e.g. an Outlook Web Access login screen.
User enter their AXS Guard credentials, such as a one-time password generated by a DIGIPASS token.
If the authentication is successful, the user’s application credentials - securely stored on the AXS Guard - are forwarded to the application server; the user is automatically and transparently authenticated with the application.

Outlook Web Access Login Page

Application Credentials

Credential replacement only works if the user’s application server credentials are known by the AXS Guard. The credentials must be entered and updated via the administrator tool or via the application’s login page if password auto-learning has been enabled on the AXS Guard appliance. Users must be granted access to the administrator tool to enter or update their application credentials, unless password auto-learning has been enabled.

The following application username formats are accepted:

Classic usernames, e.g. Bob, Alice
Windows login names, e.g. DOMAIN\user (this format is not supported by RDG servers)
Internet-style usernames, e.g. user@domain

Password Auto-learning

The AXS Guard reverse proxy features a password auto-learning option, so that users can provide or update their application server password via the login screen of the application. The AXS Guard safely stores the provided application server password in the user’s AXS Guard profile for future use.

The password auto-learning feature allows you to implement DIGIPASS authentication; the user authenticates with the AXS Guard using his / her application password in combination with a one-time password generated by a DIGIPASS token. The application password and the one-time password are entered as a single string using a separator string between both passwords. The password separator string is defined by the system administrator, e.g. applicationpassword#@#axsguardpassword.

After successful authentication, the one-time password is stripped by the AXS Guard; the remaining part of the entered authentication string (the application password) is saved in the user’s AXS Guard profile for future use and forwarded to the application server.

Important

The application password should always precede the password separator string and the AXS Guard password, otherwise authentication will fail.

Password Auto-Learning

A user on the Internet enters his application password, a password separator string and a one-time password generated by a DIGIPASS token.
The AXS Guard verifies the submitted one-time password.
If the one-time password is valid, the application password is saved in the user' AXS Guard profile for future use.
The saved application password is forwarded to the application server to authenticate the user.

The next time the user logs in, (s)he will only have to enter a one-time password, as the application password was already provided in a previous session.

Session Management

Session management is an easy solution to secure unprotected websites. It offers the possibility to use a customized login page for your applications and can be used with or without credential replacement. Users will be invited to log in via the configured AXS Guard login page. If login is successful, a session cookie will be created and the user will be redirected to the configured URL or application.

Session Management

Application-provided Authentication

The following authentication methods are supported:

No authentication
Basic authentication
Form-based authentication

Authentication provided by the Application Server

Allowed Combinations

The following authentication combinations are supported by the AXS Guard reverse proxy. Invalid combinations will trigger a validation message.

AXS GUARD / Application	None	Basic Authentication	Form-based Authentication
None	Supported	Supported	Supported
Basic Authentication	Supported	Not supported	Supported
Credential Replacement	Not supported	Not supported	Supported
Session Management	Supported	Supported	Supported
Session Management with Credential Replacement	Not Supported	Supported	Supported

NTLM Suppression

NTLM is suppressed by default by the reverse proxy as it is a connection-oriented protocol which is considered insecure for external authentication. The authentication is associated with the TCP connection, rather than the individual HTTP requests it transports.

Using NTLM authentication over the Internet would jeopardize the security of your application server by allowing authenticated requests from a first client, followed by unauthenticated requests from a second client. This means the application server would wrongfully associate the privileges of the first client with those of the second client.

If you have application servers which are configured for NTLM authentication, we strongly recommended that you reconfigure them to either enforce form-based or basic authentication.

Brute Force Attack Protection

The AXS Guard can be configured to block brute force attempts at the following levels:

The user level: consecutive failed logins from the same user are blocked, regardless of the source IP from which a suspected attack originates. Anonymizers are herewith rendered ineffective.
The host level: consecutive failed logins from the same source IP are blocked, regardless of the account that is used to launch a suspected attack.

As soon as an attack is detected and a user account is locked, AXS Guard administrators are notified via e-mail. See the Authentication guide for additional information.

Feature Activation

Log in to the AXS Guard appliance.
Go to System > Feature Activation.
Enable the reverse proxy option and update your configuration.

Getting Help

Click on the help button in the top right corner for assistance.

Getting Help

HTTP Servers

Go to Reverse Proxy > HTTP(S) > Login pages to add custom login pages for applications for which you intend to use session management.

Login Pages

Field	Description
Name	Enter a unique name for your login page. You will be able to select your saved login pages under Reverse Proxy > HTTP(S) > Servers > Name > Authentication for applications which will be using Session Management.
Description	Provide a brief description for your login page here (optional). The description will be visible in the Login Page drop-down list.
Form Title	The page title is shown at the top of the login page. The default message is "This site requires authorization".
Login Error	The error message to be shown when user authentication fails. The default message is "Login failed!".
Username Label	The label for the username field in the login page. The default string is "Username".
Password Label	The label for the password field in the login page. The default string is "Password".
Login Button Text	The text to be shown on the login button. The default text is "Login".
Enable Branding	Enable to configure the color scheme and corporate logo of your login page. Additional options will appear.
Background Color	Select the background color of the login page. If your are using Internet Explorer, you must enter the HTML color code. Each color code contains the "#" symbol and 6 letters or numbers. Only the hexadecimal format is supported, e.g. #2F323A.
Text Color	Select or enter the text color of the login page. If your are using Internet Explorer, you must enter the HTML color code. Each color code contains the "#" symbol and 6 letters or numbers. Only the hexadecimal format is supported, e.g. #2F323A.
Login Button Color	Select the color of the login button. If your are using Internet Explorer, you must enter the HTML color code. Each color code contains the "#" symbol and 6 letters or numbers. Only the hexadecimal format is supported, e.g. #2F323A.
Login Button Text Color	Select the text color for the login button. If your are using Internet Explorer, you must enter the HTML color code. Each color code contains the "#" symbol and 6 letters or numbers. Only the hexadecimal format is supported, e.g. #2F323A.
Company Logo	Upload your company logo. The logo will be shown on the login page. Use one of the following formats: jpeg, gif or png. 5Mb is the maximum allowed file size.

Creating HTTP(S) Entries

Go to Reverse Proxy > HTTP(S) > Servers.
Click on the + button.
Enter the options and parameters as explained in the tables below.
Save the entry when finished.

Option	Description
Name	Enter a name for the reverse proxy entry.
Description	Add a description for the reverse proxy entry (optional field).
Enabled	Check to enable the entry, uncheck to disable the entry.

Connection Settings

Application Server Properties

Option	Description
Application	A set of predefined applications is available to simplify configuration. Appropriate filters are automatically added for each application type, for example the public, exchange and exchweb OWA base paths. Select Unlisted Application to configure your own, custom application server.
Hostname or IP	The hostname or IP address of the application server in your network.
TCP Port	The TCP port on which the application server is listening.
Keep-alive	Check to enable persistent connections between the AXS Guard appliance and the application server.
Supports HTTP/2 Protocol	Enables the HTTP/2 protocol for application servers which support it (RFC 7540). HTTP/2 is the evolution of the HTTP application layer protocol and focuses on making more efficient use of network resources. Several tools are available for debugging, testing and using HTTP/2, e.g. curl. curl --http2 -I -v https://www.example.com > HEAD / HTTP/2 > Host: www.example.com > user-agent: curl/7.86.0 > accept: / > * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.2 (OUT), TLS header, Supplemental data (23): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.2 (IN), TLS header, Supplemental data (23): < HTTP/2 200 HTTP/2 200

AXS Guard Appliance Connection Properties

Option	Description
Hostname(s)	The names entered in this field must match the names you configured in your public DNS record(s). A unique hostname is required for each application server in your network. If left empty, any name which resolves to the public IP of the AXS GUARD will point to the application server specified in the first reverse proxy entry. It is therefore recommended to add a catch-all entry.
Accept Requests From	Select the zone. The Custom Zone option allows you to define your own zone.
Accept Requests on Interface(s)	Select the appropriate Internet and/or DMZ interfaces. This field only appears if you selected Custom Zone.
Accept Requests on IP Address(es)	Enter one or multiple public IP addresses. This allows you to restrict connections to specific IPs, rather than allowing connections to an entire zone. This field only appears if you selected Custom Zone.
TCP Port	Enter the external port to be used by Internet clients.
Keep-alive	Check to enable persistent connections between the client and the AXS Guard appliance .

AXS Guard Request Properties

Response Timeout

This field allows system administrators to specify a timeout for reverse proxy requests. 60 seconds is the system default. Change this value if you have an application server which takes an excessive amount of time to answer requests.

Lowering the value will allow the reverse proxy to exit gracefully and inform users more quickly that a timeout has occurred. Increase this value if you have an application server which routinely takes a longer time to answer requests.

Security Settings

Option	Description
Secure Connection	Select to enable SSL or TLS between the AXS Guard appliance and your application server.

Option	Description
Secure Connection	Select to enforce SSL or TLS between Internet clients and the AXS Guard appliance.
Certificate Common Name (CN)	Enter the name to be used in the SSL certificate. The browser of the client will issue a Domain Name Mismatch warning if the FQDN entered in the URL field does not match the CN of the certificate. You may use an unqualified domain name if the certificate is issued for a server in your system domain, e.g. application. The system domain will automatically be appended to the provided name. The AXS Guard system domain is configured under System > General. Use a fully qualified domain name (FQDN) ending with a period if the certificate is issued for a server in another domain, e.g. `application.notmysystemdomain.com.`.
Certificate	Select the appropriate certificate from the drop-down list. Go to PKI > Certificates for an overview of configured certificates, to import or to create a new server certificate for your reverse proxy entry. Select `new - Generate a self-signed certificate` to generate a new certificate on the fly. Note that self-signed certificates must be added to the client’s trusted root certificates for connections to succeed. This is not required when using certificates that have been signed by a trusted root CA.
Current Certificate	This read-only field shows the details of the configured certificate.

Option	Description
Restrict Access Based on IP Address	Enable to allow IP address restrictions. To protect system assets, prevent unauthorized access and lower the risk of attacks, it often makes sense to limit user connections to a specific IP address or IP address range.
Allowed IP Addresses	Enter the IP ranges or addresses which are allowed to connect. Connections originating from other IP addresses will be denied. Following are examples of valid entries: `192.0.2.0/24`, `203.0.113.10`, `203.0.113.10/32`.

Option	Description
WebSockets	Check to support the WebSocket protocol. WebSocket is a protocol which provides full-duplex communications over a single TCP connection (RFC 6455).
WebSocket Endpoint(s)	This option is only visible if the WebSockets option has been enabled. Enter your WebSocket application endpoints, e.g. `/foo/mywebservice`.
RPC over HTTP	Enable to support client applications which use RPC over HTTP, such as Outlook Anywhere.

Request Filtering

Option	Description
Allowed Path(s)	One of the security features of the reverse proxy is the possibility to enforce URL restrictions. For example, an application server has various URLs which are accessible from the Internet. Let’s assume the following paths are accessible: `http://intranet.example.com/public` and `http://intranet.example.com/private`. By only adding `/public/` as a path, access from the Internet will be restricted to `/public/`, while requests for `/private/` will be blocked. Multiple base paths can be added.
Denied Requests	URLs matching the specified patterns or parts thereof, will be blocked. You can use regular expressions to define patterns. See the section about request filtering for additional information.
Allowed Requests	URLs matching the specified patterns or parts thereof, will be allowed. Use the same regex syntax as explained in the request filtering section.
Override RFC Compliance Check	The reverse proxy is designed to filter potentially dangerous requests which could cripple your application server. One of the actions taken by the AXS GUARD appliance to protect your application servers is to only allow a specific set of characters in browser requests. This character set is defined in RFC 2396. As not all applications and servers follow the RFCs, for example Microsoft’s Outlook Web Access application, this option has been implemented to allow non-compliant characters in URLs. The non-compliant characters are automatically converted to RFC-compliant characters by the reverse proxy.
Characters Allowed in URLs	RFC 3986 provides guidelines regarding which characters may be used safely within URLs. Unsafe characters can lead to unexpected behavior. Here you can specify a set of characters that are allowed in URLs, using regular expressions.
Allow Encoded Path Separators	The reverse proxy decodes encoded URL characters by default. This may cause some applications, such as SAP business applications, to return unintended responses. Enable this option to allow URLs which contain encoded path separators, e.g. `%2F`. Encoded characters will not be decoded, but will be left in their encoded state.

Authentication Settings

Application Server

Select None if your application server does not provide any user authentication.
Select Basic Authentication if your application has been configured to use basic authentication.
Select Form-based Authentication if your application has been configured to use form-based authentication.

AXS GUARD

Select None to disable authentication against the AXS GUARD or if you intend to use the authentication method provided by your application server.
Select Basic Authentication to enforce basic authentication on the AXS GUARD side. The authentication policy configured under Authentication > Services > Reverse Proxy applies. DIGIPASS® authentication is strongly advised in this case, as the password is sent over the wire in Base64 encoding, which can be easily converted to plain text.
Select Credential Replacement to provide a single sign-on experience to users. The authentication policy configured under Authentication > Services > Reverse Proxy applies.
Select Session Management to use a custom login page for your application. Go to Reverse Proxy > HTTP(s) > Login Pages to configure a login page for your application. The authentication policy configured under Authentication > Services > Reverse Proxy applies.
Select Session Management with Credential Replacement to use your own login page in combination with credential replacement. The authentication policy configured under Authentication > Services > Reverse Proxy applies.

Field	Description	Applies to
Password Auto-learning	Enable to allow users to enter and update their application password when they log in to the application. The password will be stored in the user’s AXS GUARD profile (under Users & Groups > Users > Username > Reverse Proxy) so that it can be used for future sessions. The application server password has to be entered by users as follows: `applicationpassword#@#axsguardpassword`, where `#@#` is the default password separator string. If the option is disabled, users must enter their application server credentials (under Users & Groups > Users > Username > Reverse Proxy) by logging in to the AXS GUARD web-based administrator tool. Note that users must be granted access to the tool to perform this action.	Credential replacement and Session management with credential replacement.
Auto-learning Split String	The password separator string to be used for Password Auto-learning. `#@#` is the system default.	Credential replacement and Session management with credential replacement.
Login Page	This option is only available for applications that use session management. Select the login page for your application server. Go to Reverse Proxy > HTTP(S) > Login Pages to add and configure your own login pages.	Session management with or without credential replacement.
Session Timeout	The session timeout property specifies the time-out period assigned to the AXS GUARD session. If the user does not refresh or request a page within the time-out period, the session ends. 30 minutes is the system default.	Session management with or without credential replacement.

URL Rewriting

Option Description

Preserve Hostname When disabled, remote servers are mapped into the space of the AXS Guard reverse proxy server. The reverse proxy does not act as a proxy in the conventional sense, but appears to be a mirror of the remote server.

When enabled, the AXS Guard reverse proxy will be instructed to preserve and retain the original Host: header from the client browser when constructing the proxied request to be sent to the target server. Enabling this option is mostly useful in special configurations like proxied mass name-based virtual hosting, where the original Host: header needs to be evaluated by the backend server.

This option is enabled by default.

User Authentication

This authentication policy only applies to HTTP(S) servers; it does not affect RDG and FTP servers.

Log in to the appliance.
Go to Authentication > Services.
Select Reverse Proxy.
Select the desired authentication policy.
Update your configuration.

Field	Description
Service	The AXS Guard service to be configured. This field cannot be edited.
Authentication Policy	The authentication policy determines how users must authenticate to access the service. Go to Authentication > Advanced > Policy for an overview of policies configured on your system.
Brute Force Attack Protection	Enable to protect the selected service against brute force attacks as configured under Authentication > General.

AXS Guard Service	Authentication Policy
Reverse Proxy HTTP	OATH DIGIPASS DirectoryService RADIUS Password Passthrough
Reverse Proxy RDG	Back-end Password and OATH Back-end Password and DIGIPASS Back-end Password and OATH/DIGIPASS OATH DIGIPASS OATH or DIGIPASS Password Back-end Password Passthrough

Application Credentials for Credential Replacement

Go to Users & Groups > Users.
Select the appropriate user in the list.
Select the reverse proxy tab to enter the reverse proxy application credentials.
Update the user profile.

User-specific Reverse Proxy Settings

Field	Description
Reverse Proxy Name	Select the appropriate HTTP(S) or RDG reverse proxy entry from the drop-down list. Go to the reverse proxy menu in the left pane to add a new entry or to enable configured reverse proxy entries.
Application username	The username as known on the application or RDG server.
Application password	The password associated with the specified username.

Important

Users can only update their AXS Guard profile if their tool access level is set to user or above. To verify if a user has access to his / her profile, go to Users & Groups > Users > Username and select the AXS Guard Administration tab.
If password auto-learning is enabled, the application password is automatically added to the user’s AXS Guard profile when users enter it in the password field of the application’s login page.
Do not use the DOMAIN\username format, e.g. EXAMPLE\bob for RDG entries.

Adding Custom Applications

Go to Reverse Proxy > HTTP(S) > Applications.
Click on the + icon.
Configure the application options and save your configuration.

This option is intended for advanced administrators only (also see Custom Applications) and must be specifically enabled under System > Feature Activation > Reverse Proxy.

Accessing the HTTP(S) Logs

Log in to the AXS Guard appliance.
Go to Reverse Proxy > HTTP(S) Logs.
Click on the appropriate reverse proxy entry to view its logs.
Select the desired log type (rewrite, error, access).

Log Entry	Description
Rewrite	Shows the patterns which have been applied, the URLs which have been rewritten, redirected and/or denied.
Error	Shows any errors that occurred during login attempts.
Access	Shows details about every connection attempt.

FTP Servers

Passive and Active FTP

The FTP mode being used is determined by the client. Both modes are supported by AXS Guard, as long as the FTP connection tracker is correctly configured. See Network > NAT > NAT Helpers.

FTP Connection Tracking

Important

FTP connection tracking does not work with SFTP , as this traffic is encrypted.