ASA Anyconnect VPN using ISE IPN; need to implement as FW too
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.
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.
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
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.
We introduced the following commands: dynamic-authorization, authorize-only , debug radius dynamic-authorization .
We modified the following commands: without-csd [ anyconnect ], interim-accounting-update [ periodic [ interval ]].
We removed the following commands: nac-policy , eou , nac-settings
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...