Understanding the Role of Inline Posture
An Inline Posture node is a gatekeeper that enforces access policies and handles change of authorization (CoA) requests. An Inline Posture node is positioned behind the network access devices on your network that are unable to accommodate CoA, such as wireless LAN controllers (WLC) and virtual private network (VPN) devices.
After the initial authentication of a client (using EAP/802.1x and RADIUS), the client must still go through posture assessment. The posture assessment process determines whether the client should be restricted, denied, or allowed full access to the network. When a client accesses the network through a WLC or VPN device, Inline Posture is responsible for the policy enforcement and CoA that these devices are unable to accommodate.
Inline Posture Policy Enforcement
Inline Posture uses RADIUS proxy and URL redirect capabilities in the control plane to manage data plane traffic for endpoints. As a RADIUS proxy, Inline Posture is able to tap into RADIUS sessions between network access devices (NADs) and RADIUS servers. NADs can open full gate to client traffic. However, Inline Posture opens only enough to allow limited traffic from clients. The restricted bandwidth allows clients the ability to have an agent provisioned, have posture assessed, and have remediation done. This restriction is accomplished by downloading and installing DACLs that are tailored for specific client flow.
Upon full compliance, a CoA is sent to the Inline Posture node by the Policy Service ISE node, and full gate is opened by the Inline Posture node for the compliant client endpoint. The RADIUS proxy downloads the full-access DACL, installs it, and associates the client IP address to it. The installed DACL can be common for a number of user groups, so that duplicate downloads are not necessary as long as the DACL content does not change at the Cisco ISE servers.
The Inline Posture policy enforcement flow illustrated in the figure above follows these steps:
1. The endpoint initiates a .1X connection to the wireless network.
2. The WLC, which is a NAD, sends a RADIUS Access-Request message to the RADIUS server (usually the Policy Service ISE node).
3. Inline Posture node, acting as a RADIUS proxy, relays the Access-Request message to the RADIUS server.
4. After authenticating the user, the RADIUS server sends a RADIUS Access-Accept message back to the Inline Posture node.
There can be a number of RADIUS transactions between the Endpoint, WLC, Inline Posture node, and the Cisco ISE RADIUS server before the Access-Accept message is sent. The process described in this example has been simplified for the sake of brevity.
5. The Inline Posture node passes the Access-Accept message to the WLC, which in turn authorizes the endpoint access, in accordance with the profile that accompanied the message.
6. The proxied Access-Accept message triggers Inline Posture to send an Authorization-Only request to the Policy Service ISE node, to retrieve the profile for the session.
7. The Policy Service ISE node returns an Access-Accept message, along with the necessary Inline Posture profile.
8. If the access control list (ACL) that is defined in the profile is not already available on the Inline Posture node, Inline Posture downloads it from the Policy Service ISE node using a RADIUS request (to the Cisco ISE RADIUS server).
9. The Cisco ISE RADIUS server sends the complete ACL in response. It is then installed in the Inline Posture data plane so that endpoint traffic passes through it.
There may be a number of transactions before the complete ACL is downloaded, especially if the ACL is too large for one transaction.
10. As the endpoint traffic arrives at the WLC, the WLC sends out a RADIUS Accounting-Start message for the session to the Inline Posture node.
The actual data traffic from the endpoint may arrive at the Inline Posture untrusted side before the Accounting-Start message is received by the Inline Posture node. Upon receiving the RADIUS Accounting-Start message, the Inline Posture node learns the IP address of the endpoint involved in the session and associates the endpoint with the ACL (downloaded and installed earlier in the session). The initial profile for this client endpoint could be restrictive, to posture the client before being given full access.
11. Assuming the restrictive ACL allows only access to Cisco ISE servers, the endpoint is only allowed actions such as agent downloading and posture assessment over the data plane.
12. If the client endpoint is posture compliant (as part of the restricted communication with Cisco ISE services earlier), the Policy Service ISE node initiates a RADIUS Change of Authorization (CoA) with the new profile. Hence, a new ACL is applied at the Inline Posture node for the session. The new ACL is installed immediately and applied to the endpoint traffic.
13. The endpoint is then capable of full access to the enterprise network, as a result of the new profile that was applied to Inline Posture.
A RADIUS stop message for a given session that is issued from the WLC, resets the corresponding endpoint access at the Inline Posture node.
Best regards,
Mantej Mangat
