Configuring Address Pools

In some situations, users who connect with the Citrix Gateway plug-in need a unique IP address for Citrix Gateway. For example, in a Samba environment, each user connecting to a mapped network drive needs to appear to originate from a different IP address. When you enable address pools (also known as IP pooling) for a group, Citrix Gateway can assign a unique IP address alias to each user.

You configure address pools by using intranet IP addresses. The following types of applications might need to use a unique IP address that is drawn from the IP pool:

  • Voice over IP
  • Active FTP
  • Instant messaging
  • Secure shell (SSH)
  • Virtual network computing (VNC) to connect to a computer desktop
  • Remote desktop (RDP) to connect to a client desktop

You can configure Citrix Gateway to assign an internal IP address to users that connect to Citrix Gateway. Static IP addresses can be assigned to users or a range of IP addresses can be assigned to a group, virtual server, or to the system globally.

Citrix Gateway allows you to assign IP addresses from your internal network to your remote users. A remote user can be addressed by an IP address on the internal network. If you choose to use a range of IP addresses, the system dynamically assigns an IP address from that range to a remote user on demand.

When you configure address pools, be aware of the following:

  • Assigned IP addresses must be routed correctly. To ensure the correct routing, consider the following:
    • If you do not enable split tunneling, make sure that the IP addresses can be routed through network address translation (NAT) devices.
    • Any servers accessed by user connections with intranet IP addresses must have the proper gateways configured to reach those networks.
    • Configure gateways or a static route on Citrix Gateway so that network traffic from user software is routed to the internal network.
  • Only contiguous subnet masks can be used when assigning IP address ranges. A subset of a range can be assigned to a lower-level entity. For example, if an IP address range is bound to a virtual server, bind a subset of the range to a group.
  • IP address ranges cannot be bound to multiple entities within a binding level. For example, a subset of an address range that is bound to a group cannot be bound to a second group.
  • Citrix Gateway does not allow you to remove or unbind IP addresses while they are actively in use by a user session.
  • Internal network IP addresses are assigned to users by using the following hierarchy:
    • User’s direct binding
    • Group assigned address pool
    • Virtual server assigned address pool
    • Global range of addresses
  • Only contiguous subnet masks can be used in assigning address ranges. However, a subset of an assigned range might be further assigned to a lower-level entity. A bound global address range can have a range bound to the following:
    • Virtual server
    • Group
    • User
  • A bound virtual server address range can have a subset bound to the following:
    • Group
    • User

A bound group address range can have a subset bound to a user.

When an IP address is assigned to a user, the address is reserved for the user’s next logon until the address pool range is exhausted. When the addresses are exhausted, Citrix Gateway reclaims the IP address from the user who is logged off from Citrix Gateway the longest.

If an address cannot be reclaimed and all addresses are actively in use, Citrix Gateway does not allow the user to log on. You can prevent this situation by allowing Citrix Gateway to use the mapped IP address as an intranet IP address when all other IP addresses are unavailable.

Intranet IP DNS registration

If an intranet IP is allotted to a client machine and after VIP tunnel establishment, VPN plug-in checks if that client machine is domain joined. If the client machine is a domain-joined machine, VPN plug-in initiates the DNS registration process to tie the machine’s host name intranet with the allotted intranet IP address. This registration is reverted before tunnel de-establishment.

For successful DNS registration, make sure that the following nsapimgr knobs are set. Also make sure that the authoritative DNS server is set to allow “non-secure” DNS updates.

  • nsapimgr -ys enable_vpn_dns_override=1: This flag is sent to the NetScaler Gateway VPN client along with the other configuration parameters. If this flag is unset and when the VPN client intercepts a DNS/WINS request, it sends a corresponding “GET /DNS” http-request to the NetScaler Gateway virtual server over the tunnel to get the resolved IP address. However, if the ‘enable_vpn_dnstruncate_fix’ flag is set, the VPN client forwards the DNS/WINS requests transparently to the NetScaler Gateway virtual server. In this case, the DNS packet is sent as is to the NetScaler Gateway virtual server over the VPN tunnel. This helps in cases when the DNS records coming back from the name servers configured in the NetScaler Gateway are huge and do not fit in the UPD response packet. In this case, when the client falls back to using TCP-DNS, this TCP-DNS packet reaches NetScaler Gateway server as is, and hence the NetScaler Gateway server makes a TCP-DNS query to a DNS server.

  • nsapimgr -ys enable_vpn_dnstruncate_fix=1: This flag is used by the NetScaler Gateway server itself. If this flag is set, NetScaler Gateway overrides destination for the “TCP-connections on DNS-port” to the DNS servers configured on NetScaler Gateway (instead of trying to send them to the DNS-server-IP originally present in the incoming TCP-DNS packet). For UDP DNS requests, the default is to use the configured DNS servers for DNS resolution.

For more information on setting these knobs, see

Configuring Address Pools