×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

ASA Anyconnect VPN using ISE IPN; need to implement as FW too

Unanswered Question
Dec 18th, 2013
User Badges:

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Michael Mistretta Mon, 10/06/2014 - 16:10
User Badges:

Hi,

 

were you able to get this to work?

I am having the same issue. Would you happen to have a working config example?

 

 

much appreciated!

Mike

dirkmelvin Tue, 10/07/2014 - 07:14
User Badges:

I will post my ASA config later today after I scrub it some. Also, my core switch config. Assuming my old brain can remember. :)

 

dirkmelvin Wed, 10/08/2014 - 15:40
User Badges:

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.

Michael Mistretta Wed, 10/29/2014 - 18:36
User Badges:

Hi Dirk,

 

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

Marvin Rhoads Wed, 10/08/2014 - 20:52
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

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.

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

dirkmelvin Thu, 10/09/2014 - 07:06
User Badges:

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.

 

 

Actions

This Discussion