Cisco ISE Part 8: Inline posture and VPN
This is a Cisco ISE blog post series with some how-to’s for configuring the ISE deployment, This blog post series exists of 10 parts.
The blogpost Agenda:
Part 1: introduction
Part 2: installation
Part 3: Active Directory
Part 4: High Availability
Part 5: Configuring wired network devices
Part 6: Policy enforcement and MAB
Part 7: Configuring wireless network devices
Part 8: Inline posture and VPN
Part 9: Guest and web authentication
Part 10: Profiling and posture
This week, part 8: Inline posture and VPN
The fourth ISE node role is inline posture. This appliance can be placed in your network for devices which don’t support CoA (Change of authority). Cisco ASA doesn’t support CoA yet (but will come in the near future). This role is hardware appliance only, the VM is not supported.
This node is a gatekeeper that can enforce policies and handles CoA. After initial authentication of a client, the client still must go through posture assessment.
There are 3 possible modes:
- Router mode: This is a L3 hop in your network. This node is default gateway for clients. Only static routes are available!
- Bridge mode: is transparant in your network
- Maintenance mode: takes node offline, traffic should be uninterupted, this is de default mode
Offcourse, the node can be in high availability mode. Keep in mind, the heartbeat requires a direct ethernet cable between both nodes on both failover interfaces (eth2 + 3). Switched links are not supported. There is no mechanism that automatically syncs config changes mode on the failover node if the first node is unavailable. Use the “Syncup peer node” button for this.
For hardware installation: eth0 = trusted, eth1 = untrusted. Clients are always placed on the untrusted interface.
In bridge mode, having the same IP address on eth0 and 1 is recommended. Remember to keep the routing table on the node accurate.
If you’re using this node behind a VPN ASA, don’t configure the MAC address in a MAC filter for a directly connected ASA without entering the IP address. Without this IP, a policy bypass is allowed!
Next week part 9 of this blog post series: Guest and web authentication