Use Sites to control how users' traffic is handled.
Every Entitlement you configure must relate to a default Site, which is that Entitlement's home. This will allow the multi-tunnel network driver to set up a tunneled connection to each Site following the Software Defined Perimeter model. Once a connection is established to a Gateway, the Client sets up the Client routes to send the traffic down the appropriate tunnel. The Gateway will then route the tunneled traffic on to the protected network.
Appgate SDP supports the use of SNAT and non-SNAT, as well as options for setting a tunneled default route from devices.
Client Routing
The multi-tunnel virtual network driver has two ways of setting routes: Entitlement Based Routing and Site Based Routing. A special case for using Site based routing is when you want to use a default gateway for the traffic.
Entitlement Based Routing (EBR). The Gateway sends resolved to the Client. These are used to configure the required routes to the Sites.
This is the default setting and has the advantage that it is automated. The routes follow the Entitlements.
Subnet Based Routing (SBR). Static subnets are used by the Client to configure routes to Sites. They may be used with Entitlement Based Routing.
These routes need to be manually added in System > Sites > Client Routing.
EBR and SBR can be used concurrently.
There are pros and cons for each of these methods, and the issue of route complexity should be taken into consideration.
Route complexity
EBR is based on Entitlements. This means you can end up with hundreds of individual /32 routes that might all fall within one subnet. Mobile operating systems are not made to work with those levels of complexity. Moreover, the use of Cloud-based name resolvers means you end up with many, frequently changing Entitlements that require the mobile VPN service to be restarted on each change. These issues result in unreliability, leading to a poor user experience. Appgate SDP Clients therefore use a route optimization algorithm to try to mitigate these effects.
If you plan on deploying on iPadOS, iOS, Android, and ChromeOS, configure the system to take full advantage of this route optimization functionality. Route optimization ignores more specific routes if they are already covered by other routes, so if a /22 route is specified then none of the 1024 /32 routes it contains would be set up by the Client. To take advantage of route optimization you have two options:
Create an Entitlement for your subnet (/22) network using the block rule. A /22 route will be set and all traffic will be forwarded to (and blocked at) the Gateway. The EBR-generated /32 allow rules will not need a matching route setting because they are more specific (/32 vs /22). Similarly, the /32 rule will be allowed by the Gateway because the most specific rule wins. By adding a Condition to the block Entitlement, you can restrict which users or devices this will apply to (such as mobile devices).
Add a Site Based Routing /22 subnet (as well as using EBR normally). This will apply to all users of the Site.
Routing tunneled traffic
Clients establish a secure tunneled connection to an available Gateway on each Site based on preset weighting. The multi-tunnel network driver is assigned an IP address from the IP pool, so tunneled client-to-Gateway connections appear like any other network-connected device. The tunnel supports many protocols, such as TCP, UDP, GRE, and ICMP, as well as both up and down traffic. This allows for the deployment of more complex systems such as IP telephony.
The system has default IP pools provided for both IPv4 and IPv6. Support is provided so tunnel traffic can be of either type. However, IPv4 tunneled traffic will always use the IPv4 tunnel and IPv6 traffic will use the IPv6 tunnel.
See IPv4 and IPv6 pools for more information.
Each user or device will present the same IP address on all Sites (unless IP pool mappings are used). The Gateways on each Site could be seen as virtual routers to the tunneled IP pool address range used by the multi-tunnel virtual network drivers.
Disable Source NAT on Gateways is disabled by default, so Gateways will perform source NAT. This provides immediate compatibility with most network environments. This is not ideal for traceability however, so there is an option to log the user’s NAT-IP and NAT-port which can be enabled by selecting the Log NAT-IP and NAT-port checkbox in the Edit Site page at Sites > General.
Some of the options detailed below work with Disable Source NAT on Gateways enabled. In this mode, care should be taken to ensure the Gateways' local network supports ARP (or Neighbor Discover [ND] in IPv6 networks), as this is used to advertise the non-SNATed IP addresses the Gateway is handling.
NOTE
Most Cloud environments do not support ARP/ND.
The following sections detail some typical scenarios that cover how tunneled traffic would be routed in Appgate SDP deployments.
Simple single network (using SNAT)
In the example below, all user traffic (from the IP pool 192.168.100.64-192.168.100.254) appears to be coming from the Gateways' IP addresses (192.169.100.10, .11 and .12). All the traffic is routable on the local network (behind the Gateways) because, in this example, the IP pool and the local network share the same subnet. The IP pool is set so it does not overlap with the addresses of the machines on the local network.
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 must be maintained so a detailed audit trail can be established. There is a Site option to enable NAT-IP and NAT-port logs which adds two additional audit log records to the IP access audit log.
Multiple, larger routed networks (using SNAT)
In enterprises, multiple networks may exist and users require separately managed IP pools. As long as Disable Source NAT on Gateways is disabled, this will work as before with the Gateways performing SNAT from the 192.168.100.64-254 address range to the 172.17.111.x IP address (shown in black) of the respective Gateway.
In larger networks, for example with 4000 users, a /20 IP pool might have to be specified. Because Disable Source NAT on Gateways is disabled, each user will be assigned a unique source port per TCP/UDP stream on the Gateway’s IP address. With 4000 users on a Gateway, each with 16 Actions, it will approach the 65535 limit for the number of streams that can be established per IP address.
When Gateway source NAT is in use, the SNAT pool feature makes it possible to add multiple sequential IP address aliases on a Gateway interface (shown in gray) to the SNAT pool. This multiplies the SNAT connection stream limit by the number of selected interfaces.
With only one IP address configured on an interface, there is no requirement to configure the SNAT pool.
With two or more IP addresses configured, the first IP address will always be used if SNAT pool is not enabled anywhere.
With two or more IP addresses configured, all the IP addresses configured with SNAT pool will be used.
With two or more IP addresses configured, and all but one of the IP addresses configured with SNAT pool, the addresses with SNAT pool enabled will be used for outbound connections to the (protected) hosts leaving the remaining one available for inbound Client connections.
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 must be maintained so a detailed audit trail can be established. There is a Site option to enable NAT-IP and NAT-port logs which adds two additional audit log records to the IP access audit log.
Multiple routed networks (without SNAT)
If you plan to use down rules (reverse connections) or need an audit trail (by IP address), then you should enable Disable Source NAT on Gateways. Now the IP addresses of the Clients are visible on the protected network and will appear to be coming from the 192.168.100.64-254 address range, not the Gateway's IP address.
The user traffic 192.168.100.64-254 will follow the default gateway routing, which in the example below might be set to 172.17.111.1. The route added to the router ensures any reverse traffic destined for the IP pool will be correctly routed over the 172.17.111 network to the Gateways.
The Gateways use proxy ARP to announce these on the local (172.17.111.0/24) network. By adding the route 192.168.100.64-254 to the local network interface IP of the router, the router will do an ARP request on its local network. Each Gateway will respond to ARP requests for tunnel IPs that are currently connected to that Gateway. When a failover event moves the tunnel IP from one Gateway to another, the new Gateway will send a gratuitous ARP (an unsolicited ARP message that a device sends to itself to check for duplicate IP addresses) to notify the router of the change and to update its ARP table. Because the tunnel IP can now be announced on any Gateway, all Gateways are active in this setup.
NOTE
There is no state information that needs to be shared between Gateways, which makes Gateways linearly scalable.
Routing using IP aliases (without SNAT)
There is a use case in which some firewalls do not allow you to set additional routes to the local network interface. In this situation, a slightly different configuration can be used.
A second IP address alias and subnet mask is added to the router's local network interface. The IP/subnet 192.168.100.1/24 must encompass the IP pool address range used by Appgate SDP (192.168.100.64-254). By adding this to the local network interface of the router, the router will perform an ARP request for IP addresses in the range 192.168.100.2-254 on the local network. Each Gateway will respond to these ARP requests for tunnel IPs that are currently connected to that Gateway, so it will now behave in the same way as for the previous example.
While not required, this example also shows IP address aliases within the same subnet on the Gateways (which must sit outside the IP pool address range to avoid any IP conflicts).
Default gateway
By default, Appgate SDP performs split-tunneling. EBR or SBR captures and routes specific traffic for the protected hosts, and the remaining traffic (such as Internet access) is untouched by Appgate SDP.
It is possible to configure Appgate SDP to route all remaining traffic through a tunnel from the user's device to allow the use of a remote default gateway (accessed through an Appgate SDP Site). This is typically used when a security Policy requires the users' traffic to be firewalled, filtered, or processed by a specific network Appliance.
NOTE
This configuration is not recommended for the multi-user Client.
Configuring a default gateway
To configure a default gateway:
Set up a separate default gateway Site to be used as the destination for the default gateway traffic.
In Site > Client Routing, enable Route all traffic through tunnel. This will disable split-tunneling and any remaining traffic will now be captured and routed to the default gateway Site.
This is a special case of SBR, so you need to add an Entitlements Action for the Site with an ALLOW traffic rule set for 0.0.0.0/0 and/or ::0/0, with port range 1-65535 to allow the traffic through the Gateways' firewall.
NOTE
Only one default route should be assigned to any connecting device. (See Geo-based access if you operate several default gateways.)
Exclude your local network
If you want to exclude your local network so you can still use printers, etc., you can create another Entitlements Action with a suitable EXCLUDE route rule.
NOTE
The EXCLUDE route features is not supported on Android.
Alternative default route
There are occasions where the users' traffic needs to be handled differently from the appliance generated traffic (i.e., LDAP queries). By using an alternative default route for all user traffic you can send that traffic to a different default gateway.
In the Sites page, select the Site for which you want to use an alternative default route. Under Tunneling, enable Alternative default route for all user traffic and options will appear to set both IPv4 and IPv6 addresses for the default gateways.
In the example below, all user traffic (from the IP pool 192.168.100.64-192.168.100.254) appears to be coming from the Gateways' IP addresses (172.17.111.10,11,12). The IPv4 address for the alternative default route for tunneled traffic has been set to 172.17.111.2, which is applied to all three Gateways. The appliance's own traffic continues to be sent to 172.17.111.1.
.png?sv=2022-11-02&spr=https&st=2026-04-16T22%3A50%3A47Z&se=2026-04-16T23%3A11%3A47Z&sr=c&sp=r&sig=hDnPGba86TXaXNi6WVNm%2FuDBk%2BDcs%2Fg4e3%2BmWpBpyZc%3D)