Using the 700wl Series System
Controller. If the client is using a real IP address, all sessions must be tunneled back through the
original Access Controller.
• NAT provides some amount of protection to a client since no device other than the Access
Controller can talk directly to the client. This provides rudimentary firewall protection.
• Allowing NAT can ensure that a client will be able to successfully communicate with the network. If
NAT is not allowed, and a client has an IP address that is not within the subnet used by the Access
Controller, return packets will not be able to reach it. This can occur if the client uses a static IP
address or receives an IP address from an external DHCP server.
However, certain applications may require a host or server system to know the actual IP address of a
client. Some examples include multi-player games, file transfer in Instant Messenger applications, and
other peer-to-peer applications.
There is one case where NAT will always be used, regardless of the NAT setting specified by the Access
Policy and that is when PPTP/L2TP is enabled as an encryption protocol.
NAT and VPN Tunneling
The use of VPN tunneling affects IP addressing and NAT. If PPTP or L2TP is enabled for an Access
Policy, then addressing works as follows:
• The initial DHCP request is taken to be a request for an outer tunnel address, and NAT is always used
regardless of the NAT setting in the Access Policy.
Note: A side-effect of this behavior is that if encryption is —Allowed but not Required“ in the Access
Policy, and a client connects without using a tunneling protocol, that client will always receive a
NAT‘ed IP address upon making a DHCP request. The client will avoid being NAT‘ed only if the
client‘s group allows static IP addresses, and the client actually uses a static IP address.
• The inner tunnel address is assigned per the Access Policy NAT setting, as discussed above.
However, if Real IP mode is used, the client’s IP address is assigned as specified through the
Tunneling Configuration page—either via the external DHCP service or from a specified address
range.
Layer 3 Roaming Support
One of the key features of the 700wl Series system is its support of layer 3 roaming—enabling clients to
move physically between access points without having to reauthenticate or lose their existing sessions.
Because the 700wl Series system identifies clients by MAC address, it is simple to detect when a device
roams. A Linger Timeout determines the length of time a client has to complete a roam, that is to appear
at a new physical location after disappearing from the old physical location. The settings for timing out
a roaming client are part of the client’s assigned Access Policy; different clients can have different
settings and a given client can have different settings depending on their location, time of day, and so
on. Configuring the Linger Timeout is discussed in
Chapter 4, under Access Policies: The Timeout Tab on
page 4-59.
If the client completes the roam before the linger time has expired, no reconnect or authentication is
needed—the client’s connection state is maintained intact. Only if the client fails to complete the roam
before the linger timer expires does the system decide that the client has actually disconnected and logs
it off.
HP ProCurve Secure Access 700wl Series Management and Configuration Guide 2-23
