IP pools are used to allocate an internal IP address to the client once the user has been successfully authenticated. This IP address is assigned to the virtual tunnel interface for client-to-Gateway communication.
To ensure the IP pool size is sufficient to support all concurrent users, you may need to create a new IP pool or extend an existing pool of addresses.
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.
For more information about how tunneled traffic is handled in AppGate ZTNA, refer to Routing Client Traffic.
Where IP pools are used
IP pools are used for the device's tunnel IP address or for an alternative, mapped tunnel IP address presented on a specific Site.
Tunnel IP address
The IP pool is used by the Controller to assign a unique internal IP address to each tunnel adapter on client devices. Different IP pools can be assigned to specific user groups by linking a named IP pool to an identity provider. Refer to Identity Providers for more information.
IP Pool Mappings
IP pools are also used when configuring mapped IP addresses.
The client's IP address visible on the protected network is assigned from the IP pool (based on IdP settings) and will be the same on all Sites. IP pool mappings are useful when Disable Source NAT on Gateways is enabled and clients connect to more than one WAN-connected Site. Having just the one tun IP address presented on all Sites can cause routing issues, as the same tun IP will be announced from two or more Gateways on different Sites - all connected on the same network/WAN.
To mitigate this problem, the AppGate ZTNA system includes an IP Pool Mappings feature that allows the client to present a source address from a different IP pool on a specific Site. This concept can be expanded to as many Sites as needed to support your environment.
This feature ensures that any reply sent to the client, such as when the user is making a VOIP call, is routable on the network/WAN. Additionally, Geo-claims can be used to ensure optimal routing is used by switching the active entitlement from one Site to another based on the user/device location.
Mapping options
Mapping can be done in two different ways depending on the use case: Translation or Allocation.
For example, a user connects to AppGate ZTNA with a policy that includes access to resources on two WAN connected Sites (DC1 and DC2).
Translation should be used when you have smaller IP pools (/24) and your entire user community will be using the mapped Site. This requires that the mapped IP pool range is identical, as the IP address will be translated to the same place in the new range.
Tunnel pool for all users = 192.168.100.0/24
Site mapping pool for DC1 AppGate ZTNA Site = 10.1.1.0/24
Site mapping pool for DC2 AppGate ZTNA Site = 10.2.2.0/24
When traffic hits DC1, the AppGate ZTNA Gateway maps the assigned tun IP address (source) 192.168.100.50 to the corresponding address 10.1.1.50 in the mapped pool for DC1. When return traffic is received by the Gateway on Site DC1, it is NATed back to the original tun IP 192.168.100.50. If traffic hits DC2 instead, it will appear on the network as 10.2.2.50 and again return back the tun IP 192.168.100.50.
Allocation should be used when you have larger IP pools (/16) and only a small portion of your user community will be using the mapped Site. This requires that the mapped IP pool range is adequate for the number of users on the Site.
Tunnel pool for all users = 192.168.100.0/20
Site mapping pool for DC1 AppGate ZTNA Site = 10.1.1.0/26
Site mapping pool for DC2 AppGate ZTNA Site = 10.2.2.0/26
When traffic hits DC1, the AppGate ZTNA Gateway maps the assigned tun IP address (source) 192.168.100.50 to 10.1.1.13 on a first come, first served basis. The next user will get 10.1.1.14. When return traffic is received by the Gateway on Site DC1, it is NATed back to the tun IP 192.168.100.50. If traffic hits DC2 instead, it will appear on the network as 10.2.2.17 and again return back the tun IP 192.168.100.50.
NOTE
This feature still supports optimal HA at each Site by moving the mapped tunnel IP to another healthy Gateway.
How IP pool address assignment works
There are three terms to describe IP address assignment:
Current. The IP address is included in a device's entitlement token for its lifetime (max 7 days); it may be in active use until the token expires.
Leased. The IP address is reserved for the device for a period of X days after the entitlement token expires.
Associated. The IP address remains linked to the device.
Once an IP address has been assigned to a device by issuing an entitlement token, then it will be reported as in current use until that token expires. This may be some considerable time after the user signs out.
When the entitlement token expires (the IP address is no longer in active use), it will remain leased for the lease period (default of 30 days). This lease ensures that the same IP address will be re-assigned to a specific device next time it connects. This is done to improve user experience and make audit logs more consistent. The lease time can be set for each pool defined.
When the lease time expires, the IP address remains associated to that device. It will always be re-assigned to that device as long as it has not been re-assigned to another device in the meantime. Associated IP addresses are re-assigned to new devices when there are no new IP addresses in the pool, using the 'longest time unused first' model. Any existing association is then lost.
IP pool size
Use the IP Pools UI to create a new IP pool
System configuration and networking can have a significant effect on the size of the required IP pool. Plan for this and consider the following points before deploying AppGate ZTNA:
The default IPv4 and IPv6 ranges allow for only 254 addresses out of the box.
Every device that connects will be assigned its own IP address from the pool. If every user has a desktop and mobile phone, then the IP pools should be set to
. This becomes more complicated if users have virtual desktops. In this case, those users may connect from a brand new device each time, consuming a new IP address. In such cases the IP range must be much bigger and/or the lease time reduced accordingly. If multiple identity providers are configured, even though it's same user signing in on the same device, AppGate ZTNA considers it to be a different user. Therefore, every time a user connects using a different IDP, another unique IP address will be consumed.
When using HA Controllers, allow for sufficient IP addresses for all new users in the event that one of the Controllers becomes unavailable. The IP pool is split between the Controllers equally in respect of assigning new IP addresses. However, existing (current, leased, and associated) IP addresses can be renewed by any Controller. As a result, the available address range for just new users will be degraded for a period of time. The sizing of the pool should be increased to allow for this (which will depend on how long a Controller might be unavailable). We recommend a minimum of and a maximum of
and a maximum of . When Gateway SNAT is being used, even though the Gateway's address is used on the network, the lP pool is still required as it is used for the traffic between the client and the Gateway.
For the IP pool mapping - translation feature (see above), its pool size needs to exactly match the original IP pool size.
For the IP pool mapping - allocation feature (see above), its pool size needs to be adequate for the number of users on that Site.
If you need more IP addresses:
Every IP pool can include multiple ranges, so you can add another range using IP pools.
You can keep entitlement token life times short. This will move any IP addresses from current to leased for signed out users.
You can reduce the lease time set for the IP pool, and this will move any IP addresses from leased to associated (which will allow the re-assignment of IP addresses).
NOTE
You cannot delete or change an existing range within an IP pool, but you can add new ranges and range exclusions.
Monitoring usage
There following tools monitor the assignment and use of IP pool addresses:
The IP pools console provides statistics on currently used and leased IPs.
Metrics report on current, leased, and total usage for each IP pool.
When any pool's currently used and leased IP addresses reach 75% of the total size, a healthcheck warning is issued.
You can see an individual user's IP address and mapped IP address(es) from the Session Details on the Dashboard.
You can see an individual user's IP address in the About screen on the client.
IPv6
You do not need a public IPv6 network to pass IPv6 application traffic, however the following elements all need to be in place:
The (protected) hosts need to have an IPv6 address on an IPv6-enabled network behind the Gateways.
The DNS server specified (used by the Gateways and the user's device) must resolve the (protected) hosts to an IPv6 address.
There must be an AppGate ZTNA IPv6 tunnel that requires:
a defined IPv6 pool
that IPv6 is enabled if using the DNS resolver
the IPv6 pool is specified in the IdP
If you are not using IPv6
If an IPv6 pool is not present, then IPv6 is disabled on the Gateways’ tun devices. This has two advantages:
It is much slower to set up both IPv4 and IPv6 tun devices on the Gateways, so session set up times are reduced.
In many situations, especially in respect to DNS, having IPv6 configured can cause users to experience slow or failed connections.
Because there is a default IPv6 pool included in all new Collectives, this check will have no immediate benefit. It is therefore recommended to remove the default IPv6 pool if it is not required in your Collective.