We already have ISE IPN on this ASA for our VPN users, but now we want to migrate it to be our Internet firewall as well.
The issue we have is that for the IPN to work, the 'inside' interface of the ASA and the 'outside' or 'untrusted' interface of the IPN have to be on the same network, so we setup two ports on the core switch to be their own VLAN. In this way any and all traffic travels through the IPN on its way to and from the ASA. It was explained to me it had to be this way for the ISE/NAC posturing.
So right now we have static routes in the ASA pointing default to the 'outside' ASA interface, and then specific internal IPs routed through the 'inside' interface to the IPN to get to the internal network.
Speaking with a Cisco tech the other day they suggested using a 'tunneled' route that would force all the VPN traffic to use the default route to the IPN, and then I could setup all my other routes to the 'new-internal' interface and that is how my non-VPN related traffic would get around.
I tried this approach yesterday, and as soon as I removed my big internal route, my VPN users complained that they lost internal connectivity.
Can anyone lend me some options here?
were you able to get this to work?
I am having the same issue. Would you happen to have a working config example?
This is our ASA config....I cleared a lot of object and other VPN configs out of it, but it is still pretty big, I think you can pick the ISE related bits out of it. But I can pare it down more if you need.
thanks much for this information.
I was able to get this working finally using a combo of techniques i had picked up on here and there. Basically i created a subnet between the ASA (inside), IPN (untrusted), and core (4500).
I create a PBR on the core that grabbed VPN subnet sourced traffic, and next-hopped it to the untrusted IPN interface. I also created a route on the core for return traffic destined back to the VPN subnet, to go through the trusted side of the IPN.
The final gotcha was making sure that the PSN that the IPN is pointing to, was the same PSN performing the posturing. From there on, everything worked.
The information you've provided is greatly apreciated
As of ASA 9.2 you can simply use RADIUS CoA with your ISE server directly from the ASA and remove the entire IPN from the picture.
See the following in the ASA 9.2 Release notes:
ISE Change of Authorization
The ISE Change of Authorization (CoA) feature provides a mechanism to change the attributes of an authentication, authorization, and accounting (AAA) session after it is established. When a policy changes for a user or user group in AAA, CoA packets can be sent directly to the ASA from the ISE to reinitialize authentication and apply the new policy. An Inline Posture Enforcement Point (IPEP) is no longer required to apply access control lists (ACLs) for each VPN session established with the ASA.
When an end user requests a VPN connection the ASA authenticates the user to the ISE and receives a user ACL that provides limited access to the network. An accounting start message is sent to the ISE to register the session. Posture assessment occurs directly between the NAC agent and the ISE. This process is transparent to the ASA. The ISE sends a policy update to the ASA via a CoA “policy push.” This identifies a new user ACL that provides increased network access privileges. Additional policy evaluations may occur during the lifetime of the connection, transparent to the ASA, via subsequent CoA updates.
Yes, I am aware of this.
I just have not had the clearance from Management to get us moved to this scenario, yet.
Since we have the physical IPN, and a VM doing everything else, the plan is to redo the IPN to a full ISE and redo the VM to be a full ISE, and have an HA pairing. Eventually. :)
I know that once we get the IPN out of the picture we will be able to remove the ISE_VPN Interface from the ASA.