Understanding Static IP Addressing with Static Pools
03/26/2020 159 People found this article helpful 485,090 Views
Description
Understanding Static IP Addressing with Static Pools
Resolution
The following is a brief description of what happens when static IP addressing occurs on the tunnel service of the appliance.
- The connecting client supplies a unique connectoid GUID. The client may also supply information about the most recent connection and indicate whether the client is resuming a tunnel that died, or it is initiating a new tunnel.
- All addresses in a static pool start out in an "available" queue. As clients connect and disconnect, the server marks each address with the GUID of the last client to use it. Disconnected addresses are available only to clients with that same GUID (presumed to be the same client) for about two minutes after disconnection. After two minutes a disconnected address goes to the end of the "available" queue; this will be the next address assigned (unless a client reports it as its most recent address, described below). Resumption of usage of the same address must be from the client with the same GUID.
- During a connection attempt, if no last-address information is supplied by the client, the tunnel service evaluates the next few addresses in the "available" queue for conflicts[1], and then assigns the first with no conflicts or acceptable conflicts to the Connect tunnel client. If fatal conflicts are found in all of these first few addresses, assignment from this pool fails; the address assignment effort continues with the next allowable pool, or it fails altogether if there are no more pools.
- If the last-address information is supplied, the server checks that the address is available; if it's within two minutes of the last disconnect the server also checks that the GUID matches the client. Non-fatal conflicts are accepted.
- If the client indicates that it's resuming a failed tunnel, the process is the same as the last-address assignment, except that an existing tunnel with this GUID is torn down and the client dumps flow information to the server in order to re-establish open sessions.
Secure NAT pools work in a similar way, except that no "available" queue is maintained; instead there is a "next-address" counter shared among all Secure NAT pools. Disconnected addresses are still reserved (same GUID only) for two minutes, and then are once again available. Realistically, they'll be reassigned, because there are several million NAT addresses to loop through before this particular address is once more the "next-address."
DHCP pools bypass all of the address reservation routines and allow the DHCP server to handle it instead.
[1] Address conflict resolution routines within the server typically will avoid an address assignment that will disrupt the user's connection.
Related Articles
Categories
Was This Article Helpful?
YESNO