The authentication is initiated from the RADIUS client on the ISA anchoring the user, based on an ISA RADIUS policy (configured under AAA) and specified on the WLAN-GW group interface. The initial Access-Accept from RADIUS can indicate if a user needs to be portal authenticated or is a pre-authenticated user. The indication is based on inclusion of a ‟redirect policy” applicable to the user, in a VSA (Alc-Wlan-Portal-Redirect, type = string). The Access-Accept can also include a redirect URL VSA (Alc-Wlan-Portal-Url, type = string) for the user. An empty Alc-Wlan-Portal_redirect VSA forces the use of locally configured redirect policy. If neither of the two VSAs are included, this indicates a pre-authenticated user, and an ESM host is created for the subscriber with a subscriber profile and other subscriber configuration from the Access-Accept, and normal ESM-based forwarding occurs for the subscriber.
It is also possible to bypass RADIUS authentication directly, using the local configuration in the config>service>{vprn | ies}>subscriber-interface>group-interface>wlan-gw>vlan-range>authentication context. When you configure this option, the system immediately creates the UE in the DSM or portal state, using the DSM or portal parameters configured under the VLAN range.
However, if a user requires portal authentication (indicated in the Access-Accept), while the authentication is pending, forwarding is restricted to DNS and portal servers via the redirect policy. The redirect policy is an IP ACL that restricts forwarding based on IP destination, destination port, and protocol, and specifies HTTP redirect for HTTP traffic that does not match any of the forwarding rules. The URL for redirect is configured in the redirect policy or provided in the Authentication-Accept. A maximum of 16 redirect policies can be created in the system, with a maximum of 64 forwarding rules across all redirect policies. During the ‟authentication pending” phase, all forwarded traffic is subjected to Layer 2 aware NAT on the ISA. The NAT policy to use for these users is configured on the WLAN-GW interface or per VLAN range under the WLAN-GW interface. After an Access-Accept has been received from RADIUS for such a user, the next HTTP packet triggers a redirect function from the ISA, and an HTTP 302 is sent to the client. The client presents its credentials to the portal and after successful authentication, a CoA is generated from the RADIUS server (triggered by the portal). The CoA message triggers creation of an ESM host with the subscriber configuration contained in the CoA, such as the subscriber profile, SLA profile, NAT profile and application profile. From this point, normal ESM- based forwarding occurs for the subscriber.
You can configure the redirect URL with the following macro attributes, which are automatically replaced with values relevant to that UE:
$MAC
This is the MAC address of the UE in the format XX:XX:XX:XX:XX:XX.
$IP
This is the IPv4 or IPv6 IP address the UE uses to generate the original HTTP request.
$URL
This is the originally requested URL, which is included as specified without special encoding (for example, using base64). Nokia recommends to only append this URL to the end of the redirect URL, to avoid URL parameter conflicts.
Example
If you include the following URL:
example.com?a=1&b=2
In the following redirect URL:
portal.omlogin?url=$URL&mac= &MAC
This results in a new redirect URL such as the following:
portal.com/login?url=example.com?a=1&b=2&mac=00:00:5e:00:53:1
For the portal server, it is not clear whether the parameters ‟b” and ‟mac” are part of the original URL or their own URL, which could lead to parsing errors.
$NASIP
This is the RADIUS IPv4 address assigned to the ISA/ESA-VM, either from the authentication policy or the CoA policy. It can be used as the destination address of a CoA.
See, Migrant User NAT Configuration for configuration information related to migrant users.