Configuring Inline Posture in Bridged or Routed Mode
To introduce an Inline Posture node in your Cisco ISE network you must first register the Inline Posture node with the primary Policy Service ISE node, configure the Inline Posture settings, and then create authorization profiles and policies that establish the Inline Posture gatekeeping policies.
The Inline Posture node is a RADIUS proxy that interfaces with NADs as their RADIUS server, making the NADs (VPN gateway, WLC) RADIUS clients. As a proxy, Inline Posture interfaces with the Policy Service ISE node as a client, making the Policy Service ISE node its RADIUS server.
Note Upon completing the following procedure, a NAD entry is automatically created for the Inline Posture node. For a standalone node, the IP address for that node is used. For an HA pair, the service IP address for the active node is used.
Guidelines for Configuring Certificates for Inline Posture
Secure communication between Administration and Inline Posture nodes requires mutual authentication. This means that not only must the Inline Posture node prove its identity to the Administration node, but the reverse is also true.
For a proper communication between Administration and Inline Posture nodes, the primary Administration node local certificate should have both Client Authentication and Server Authentication EKU attributes.
Observe the following guidelines when configuring certificates on these nodes:
The presence of certain combinations of attributes in the local certificates of the Administration and Inline Posture nodes can prevent mutual authentication from working.
The attributes are:
– Extended Key Usage (EKU)—Server Authentication
– Extended Key Usage (EKU)—Client Authentication
– Netscape Cert Type—SSL Server Authentication
– Netscape Cert Type—SSL Client Authentication
Either of the following combinations is required for the Administration certificate:
– Both EKU attributes should be disabled, if both EKU attributes are disabled in the Inline Posture certificate, or both EKU attributes should be enabled, if the server attribute is enabled in the Inline Posture certificate.
– Both Netscape Cert Type attributes should be disabled, or both should be enabled.
Either of the following combinations is required for the Inline Posture certificate:
– Both EKU attributes should be disabled, or both should be enabled, or the server attribute alone should be enabled.
– Both Netscape Cert Type attributes should be disabled, or both should be enabled, or the server attribute alone should be enabled.
Where self-signed local certificates are used on the Administration and Inline Posture nodes, you must install the self-signed certificate of the Administration node in the trust list of the Inline Posture node. In addition, if you have both primary and secondary Administration nodes in your deployment, you must install the self-signed certificate of both Administration nodes in the trust list of the Inline Posture node.
Where CA-signed local certificates are used on the Administration and Inline Posture nodes, mutual authentication should work correctly. In this case, the certificate of the signing CA is installed on the Administration node prior to registration, and this certificate is replicated to the Inline Posture node.
If CA-issued keys are used for securing communication between the Administration and Inline Posture nodes, before you register the Inline Posture node, you must add the public key (CA certificate) from the Administration node to the CA certificate list of the Inline Posture node.
You should have administrative permissions on the primary Administration ISE node.
Follow and apply the Guidelines for Configuring Certificates for Inline Posture.
Register the Inline Posture node with the primary Administration ISE node, as described in Registering and Configuring a Secondary Node. All nodes must be registered with the primary Administration ISE node to function as a member of the Cisco ISE distributed system. Be sure to check the Inline Posture check box. The Administration, Monitoring, and Policy Service check boxes are automatically unchecked.
Note Registering an Inline Posture node results in a system restart. Likewise, changes to infrastructure configurations, such as the eth1 IP address, Inline Posture mode, and high availability changes also require a system restart. The restart is automatic. However to manually restart the node from the CLI, use the application stop ise and application start ise commands.
RADIUS configuration is mandatory. At least one client and one server configuration is necessary. You need the corresponding shared secret information for both sides to complete this procedure.
Have all necessary configuration information for your installation on hand. For example, you might need the trusted and untrusted IP addresses, service IP address, the IP addresses for other Cisco ISE nodes, shared secret for RADIUS configuration, management VLAN ID, WLC, or VPN IP address, and so on. Check with your system architect for a complete list of the information you will need.
Warning Do not configure the MAC address in a MAC Filter for a directly connected ASA VPN device without also entering the IP address. Without the addition of the (optional) IP address, VPN clients are allowed to bypass policy enforcement. This access happens because the VPN is a Layer 3 hop for clients, and the device uses its own MAC address (as the source address) to send packets along the network toward the Inline Posture node.
To configure Inline Posture in bridged or routed mode, complete the following steps:
Step 1 From the primary Administration ISE node, choose
Administration > System > Deployment
Step 2 Click
in the Deployment navigation pane, and then in the Deployment Nodes page, check the
Inline Posture node
check box and click
Step 3 On the General Settings tab, check the
check box. The Administration, Monitoring, and Policy Service check boxes are automatically unchecked.
Figure 10-5 Edit Inline Posture Node
The tabs change to General Settings, Basic Information, Deployment Modes, Filters, Radius Config, Managed Subnets, Static Routes, Logging, and Failover.
Note A newly registered Inline Posture node comes up with a default IP address of 192.168.1.100, a subnet mask of 255.255.255.0, and a default gateway of 192.168.1.1. Change these values to fit your deployment in Step 3.
Step 4 Click the
tab and enter the appropriate information for the following options:
Time Sync Server: Primary, Secondary, Tertiary
DNS Server: Primary, Secondary, Tertiary
Trusted Interface (to protected network): Set Management VLAN ID (all the other information is automatically populated for these options)
Untrusted Interface (to management network): IP Address, Subnet Mask, Default Gateway, Set Management VLAN ID
Figure 10-6 is an example of a bridged mode configuration. Figure 10-7 is an example of a routed mode configuration.
Figure 10-6 Basic Information (Bridged)
Figure 10-7 Basic Information (Routed)
Step 5 Click the
tab. A newly registered Inline Posture node comes up in maintenance mode. For production purposes, choose one of the following:
Routed Mode—Provides router (hop in the wire) functionality for Inline Posture. Figure 10-8 provides an example for routed mode.
Bridged Mode—Provides VLAN mapping functionality for the subnets to be managed by Inline Posture. After checking the Bridged Mode check box, enter the Untrusted Network and Trusted Network VLAN ID information. Figure 10-9 provides an example for bridged mode.
For VLAN mapping, you should also do the following:
– Add a mapping for management traffic by entering the appropriate VLAN ID for the trusted and untrusted networks.
– Add a mapping for client traffic by entering the appropriate VLAN ID for the trusted and untrusted networks.
Figure 10-8 Deployment Modes (Routed)
Figure 10-9 Deployment Modes (Bridged)
Step 6 Click the
tab and enter the subnet address and subnet mask for the client device, or the MAC address and IP address of the device on which to filter.
You can use MAC and subnet filters to bypass Inline Posture enforcement to certain endpoints or devices on the untrusted side of the network. For example, if VPN or WLC management traffic is required to pass through Inline Posture, you would not want to subject those particular NADs to Cisco ISE policy enforcement. By providing the MAC address and IP address for these NADs on a filter, you can then access the user interface or configuration terminal by way of Inline Posture without restrictions.
MAC filters—MAC address and/or IP address on which to avoid policies
Subnet Filters—Subnet address and subnet mask on which to avoid policies
Note For security reasons, we recommend that you always include the IP address along with the MAC address in a MAC filter entry. For more information, see the Warning in Prerequisites.
Figure 10-10 Filters
Step 7 Click the
tab and enter the IP address and shared secret for the following:
Primary Server—Primary RADIUS server, usually the Policy Service ISE node
Client—Device that requests access on behalf of clients, WLC or VPN
Note WLC roaming is not supported in Cisco ISE Release 1.1.x.
RADIUS configuration is mandatory. At least one client and one server configuration is necessary for Inline Posture. For more information on RADIUS proxy services, see Proxy Service.
Figure 10-11 RADIUS Configuration
Step 8 (Optional) Check the Enable KeyWrap check box and specify the following Authentication Settings:
Key Encryption Key
Message Authenticator Code Key
Key Input Format: ASCI or Hexidecimal
Deployments that utilize wireless LAN technology require secure transmission from a RADIUS server to a network access point. KeyWrap attributes provide stronger protection and more flexibility.
Step 9 Click the
tab, and enter the following information for each Managed Subnet:
For subnets of endpoints that are in Layer 2 proximity to the Inline Posture node (such as a WLC), you must configure managed subnets. This configuration requires an unused IP address in the same subnet as the managed subnet, along with the VLAN (if any) of the subnet. You can have multiple managed subnet entries.
Figure 10-12 Managed Subnets
Step 10 Click the
tab, then enter the subnet address, subnet mask, and choose
from the Interface Type drop-down list. Repeat this step as needed for your configuration.
When the subnets of the endpoints under Cisco ISE control are Layer 3 away from the Inline Posture node, a static route entry is needed. For example, if a VPN gateway device (that sends managed subnet traffic to the Inline Posture untrusted interface) is two hops away, its client subnet needs to have a static route defined for Inline Posture. The network on the trusted side should know to send traffic to the Inline Posture trusted interface.
Figure 10-13 Static Routes
Step 11 Click the
tab and enter the IP address and port number for the logging server, which is typically the Monitoring ISE node.
An IP address and port (default 20514) for logging Inline Posture events are mandatory. This requirement ensures that the viable status of the Inline Posture node is displayed in the Cisco ISE dashboard in the System Summary dashlet, and that other log information regarding the nodes is available.
Figure 10-14 Logging
Step 12 Click
. The node restarts.
Step 13 To verify the automatically generated Inline Posture NAD listing, go to
Administration > Network Resources > Default Device
For a standalone node, the IP address for that node is used. For an HA pair, the service IP address for the active node is used.
To complete the configuration setup of the Inline Posture node, complete the following tasks, creating three DACLs, authorization profiles, and authorization policy rules: unknown, compliant, and noncompliant.
1. Creating Inline Posture Downloadable Access Control Lists
2. Creating Inline Posture Node Profiles
Note It is important to associate the appropriate downloadable access control list (DACL) with the corresponding profile. For example, the unknown DACL should be associated with the unknown authorization profile.
3. Creating an Inline Posture Authorization Policy
Creating Inline Posture Node Profiles
This section describes how to create authorization profiles for Inline Posture. You create three Inline Posture authorization profiles, as well an authorization profile for a NAD. For more information, see Cisco ISE Authorization Policies and Profiles.
All Inline Posture inbound profiles are automatically set to
so that the Inline Posture node is sure to apply these rules, instead of proxying them on to the NADs. The
is essential for client provisioning, as well as agent discovery redirection.
To create authorization profiles for NAD and Inline Posture, complete the following steps:
Step 1 Create a NAD authorization profile as described in Creating and Configuring Permissions for a New Standard Authorization Profile.
Note You can configure a RADIUS Reply Message = NAD Profile, to see NAD Profile in the RADIUS log messages for Inline Posture. This configuration can be helpful for troubleshooting at a later time.
Step 2 Create authorization profiles to Inline Posture that correspond to the DACLs you created in Creating Inline Posture Downloadable Access Control Lists.
Figure 10-18 Inline Posture Profiles
Specify the appropriate DACL for each of the following authorization profiles:
Unknown-Compliant (Pre-Posture): This profile requires that you enter a URL redirect.
From the Inline Posture Authorization Profiles page, select the Unknown-Compliant DACL name from the drop-down list, enter the following URL redirect in the text field, and click
The URL redirect appears in the Attributes Details field.
Figure 10-19 Unknown-Compliant Authorization Profile
You are redirected to a web page where you download and install an agent. The agent then scans your system. If your system passes, you are automatically granted full access. If your system does not pass, you are denied access.
IPEP-Compliant (Permit Any)
IPEP-Noncompliant (Deny All)
Figure 10-20 Non-Compliant Authorization Profile
Step 3 After you have saved each of the authorization profiles, continue with Creating an Inline Posture Authorization Policy.