This section defines the configuration and operation of the tunnel used to send the users' traffic to/from the Site's Gateways. Understand more about Tunnel architectures.
Tunnel Protocol (VPN)
Tunnel Protocol (VPN)
The tunnel itself can use either TCP or UDP. The choice of protocol does not affect the tunneled traffic from the Client to protected resources. The default protocol is TLSv23 and we recommend this is used.
NOTE
TLSv23 will use TLSv1.3 and fall back to TLSv1.2 if it is not supported.
TLS
Use TCP-based tunneling, as defined in the Appliance's 'System TLS Connection'.
DTLS
UDP-based tunneling is not recommended as it doesn't offer any significant advantages over TCP-based tunneling, and in some cases, it may even limit the functionality. This option may be deprecated in the future.
NOTE
DTLS will use the same Allowed Sources as for TLS which is defined in the appliance's 'System TLS Connection'.
You may also need to review the secure tunnel settings in the appliance configuration.
Disable source NAT on Gateways
When source NAT is disabled, the Site will see tunneled traffic originating from the user's assigned IP pool address. Source NAT is used by default. It should be used when the protected networks do not allow the Client tun IP addresses, or if connecting multiple Gateways to the same network without using IP Pool Mappings. You will not be able to use reverse IP access (i.e. TCP down) in when source NAT is in use.
One issue when using SNAT is that the relationship between the user's identity and the traffic on the local network is lost. From a security perspective there can be situations where this relationship needs to be maintained so that a detailed audit trail can be established. There is a Site option to enable NAT-IP and NAT-port logs - this will add two additional audit log records to the IP access audit log.
NOTE
Without Source NAT, you may need to configure the routing in your network (for the IP Pool ranges to the Gateways).
URL Access
When the destination in Appgate SDP is being configured as a URL (HTTP up access rule), the Gateway will act as a man in the middle, so even when SNAT is disabled on the Site, the Gateway IP address will always be used on the protected network behind the Gateway. The Gateway acts as a reverse proxy, decrypting and filtering the traffic, before encrypting it again and making a new onward connection to the protected host. The IP Access logs within Appgate SDP contain all the details about the user and the device that is connecting to the application. And the original client tun IP will be added to the HTTP request header, so the source IP of the user can also be traced by the application this way.
IP Pool Mappings
An alternative IP pool can be used to map the Client's IP address for this Site only. Mapping can be by 'translation' (10.1.1.17>10.1.100.17) or 'allocation' (10.1.1.17>10.1.100.1).
This is an optional field and only needs to be set to avoid IP routing issues in specific situations. Refer to IP Pool-mapping for more information and there is an example in Routing Client traffic.
Log NAT-IP and NAT-port
This adds two extra audit log fields which can be costly in terms of performance; so only enable this if it is needed. When the Gateways are using source NAT, two additional fields nat_src_ip and nat_src_port will be added to the ip_access audit log. This only applies in the case of ALLOW rules and only for TCP and UDP protocols. Refer to audit logs.
Alternative default route for all user traffic
Will divert all user tunneled traffic to its own default gateway. Normally when using Route all traffic through tunnel, the default gateway used will be the same as the appliance uses. When set, this IP address will be used for the tunneled traffic from users except when the tunneled traffic destined for the Gateway's local subnet. This will be routed to the default gateway the appliance uses BUT ONLY if the appliance has been configured with a static IP address (so not using DHCP).
The appliance generated traffic will continue to use the appliances default gateway (for traffic such as DNS requests, scripts making external calls, etc)
IPv4
IPv4 address of the default gateway for user tunneled traffic.
IPv6
IPv6 address of the default gateway for user tunneled traffic.
There is an example in Routing Client traffic.
Terminate tunneled HTTPS traffic using this PKCS #12 file
In order to decrypt the HTTPS streams and then reverse proxy the traffic on to the protected hosts, a PKCS #12 file is required.
The URL access feature operates as a reverse proxy when handling Client traffic. This means that the appliance requires a PKCS#12 file to terminate any http(s) connections, decrypt, URL filter and then re-establish an onward https connection to the protected hosts. URL access can support multiple PKCS#12 files, each containing a certificate (for the protected host) signed by a trusted CA and the private key. An alternative to the use of multiple certs is a wild-card cert - but this should be limited in scope because of the security implications in the event of its loss.
PKCS #12 Files
Upload one or more PKCS #12 files which comprises the relevant certificates and private key that allows Appgate SDP to intercept the encrypted traffic.
File
Select the PKCS #12 file to upload.
Password
The password for the PKCS #12 file.
Verify Upstream
All upstream servers are checked for valid certificates that match their hostnames by default. See Adding third party certificates for more details.
Once a PKCS #12 file is in place, to configure URL filtering, choose the HTTP up Action type and optionally select some HTTP methods when configuring your Entitlement.
Change IP access audit log interval
Change the default time interval between repeating IP access audit log records.
Time Interval (seconds)
Set the time interval between repeating IP access audit log entries. Default is every 120s. 0s means don't log IP accesses.
This is an important setting for system reliability. By default the system will continue to produce audit log records for established TCP connections with a repeat interval of 30 seconds. So 5000 users with 10 TCP connections for 10 hours will produce 15M audit log entries! This can have a significant effect on disk usage so the interval should be increased unless audit requirements dictate otherwise.
The 0 seconds (don't log) is also important. This can be very useful when Alternative default route for all user traffic is being used as the downstream appliance could probably do the logging. It can also be useful when Route all traffic through tunnel is enabled for the Site as this could lead to very many connections being established by for instance web pages with many 10s of embedded links.
Tunnel traffic to a fallback Site when the primary Site is unavailable
The Client will try the fallback Site when it cannot connect to this Site. Extra resources must be provided on the Gateways - failure to plan in the extra RAM (and CPU) will mean the fallback Site can quickly become overloaded with all the users from the failed Site(s). See HA for details.
Fallback Site
Select an alternative fallback Site.
NOTE
Access to the Entitlements must also be available on the fallback Site.
Use for nearest Site selection
The Entitlements' Site can be overridden with this geolocated Site.
NOTE
This must be enabled in the Policy's Override Site settings.
Use Local Client Hostname/IP to connect to Gateways
When a Client is on the local LAN it will connect using internal hostname/IP(s) instead of external ones
Associated Public IPs/Networks
The Controller will specify the use of the 'Local Client Hostname/IP' when users connect from any of these Public IPs/Networks. Multiple IPs may be specified, or a range specified using CIDR format.
NOTE
If no Local Client Hostname/IP has been defined in Gateway > Secure Tunnel Settings, the Client Hostname/IP will be used.
<