Hello, if I have an ASA that does user VPN and is the main internet access firewall, can I still protect VPN (posture assessment) with an ISE IPN? I know the ASA can do posture assessment itself, but lets say I need to use the ISE IPN, does regular internet traffic route through the IPN as well?
Yes, You are correct, you can do posture assessment with an ISE VPN. Please check the below link for more assistance:
For a simple answer is yes for most deployements however you can limit internal access for users by educating them to hit a common url on the inside so that they are redirect to either install the nac agent or run through the web agent. However most customers do not provide just internet access to vpn users so prefer to go the less complex option.
I use PBR so that all traffic doesnt route through the IPN.
*Please rate helpful posts*
Policy based routing, essentially for ipn to work with an ASA you have to use the route inside 0 0 tunneled to either the untrusted IPN interface or a router or SVI, so that all encrypted traffic hits the next hop on the inside. From the hop on the inside I like to use a PBR so that only client vpn traffic is routed through the IPN where as site to site traffic uses the global routing traffic like it should.
If a failure on the device ever occurs you are not impacting site to site vpn traffic which should be affected regardless if ISE is on your network or not.
*Please rate helpful posts*
Thank you very much for your reply Tarik.
Would you happen to have an example ASA config that addresses this?
As I have mentioned in other posts, we have an ASA 5515X that right now is only being used for AnyConnect VPN termination. With this setup we use ISE to posture all anyconnect clients. For this setup to work, per what we were told and instructed to setup, we have the "WAN" interface and the "inside" interface on the ASA, and then we have the IPN.
Both the "inside" interface of the ASA and the "untrusted" interface of the IPN have IPs in the same subnet, and both are physically connected to ports on our core switch (4507R+E this is also our networks default GW), and those ports are the only ones assigned to VLAN155. So right now, the ASA has only static routes to the inside going through the IPN.
As of this week, I created a new "company-inside" interface on the ASA. I have assigned that interface an IP, and physically plugged it into the core switch. On the core switch I created a VLAN3 and assigned it to this port.
I have given VLAN3 and IP. The "company-inside" interface IP and the VLAN3 IP on the core switch are in the same subnet.
Per TAC request I created the 0 0 TUNNELED route, saved the config and let that go overnight to see if anyone complained. All went well, no complaints.
However, when I removed the route 10.30.0.0 255.255.0.0 (IPN IP) all my VPN users were no longer able to access the internal network (which is 10.30.0.0 255.255.0.0)
So I am confused how removing that route had anything to do with VPN users, if all VPN traffic is supposed to use this TUNNELED route.
Ok, so I tried this again today.
I think the AnyConnect users are indeed now using the TUNNELED route, however, it appears that maybe the ISE/NAC part of the traffic isn't tunneled?
Again I changed my route for internal 10.30.0.0 255.255.0.0 from pointing to my IPN interface, to pointing to my CORE interface. When I did this, it seemed all my previously connected VPN users were accessing internal networks just fine, but those that were now trying to connect to the VPN, were not able to get the NAC agent popup, and therefore never able to gain network access.
The way I was able to make this work is followed -
Use the route inside 0 0 tunneled (which you have) but point it to your svi on the core.
Create and acl that matches the remote vpn subnet example 126.96.36.199/24
Map this to a PBRF and set the next hop to the untrusted interface of the ISE appliance
From IPN config (in routed mode) add a route for the vpn users (188.8.131.52/24) out the untrusted interface with the next hop set to the ASA's inside interface so that return traffic is routed properly (not the svi or you will put a routing loop for those users).
From the core add a route for the 184.108.40.206/24 network to the trusted interface of ISE.
That should give you the ability to separte which tunneled traffic hits the IPN and which traffic doesnt hit the ASA.
Just to double-check you are only dedicating this ASA to terminate VPN connections, there are not plans to also allow internet access through this firewall correct?
*Please rate helpful posts*
Looking back on your reply about PBR....I believe this is indeed my solution.
Could you possibly map that out?
From my config....my VPN users get 10.154.30.x/24
'work-inside' interface set to 10.2.250.2/29
'inside' interface is 10.155.10.10/24
'untrusted' interface is 10.155.10.11/24
'trusted' interface is 10.30.5.11/16
VLAN3 SVI 10.2.250.3/29
VLAN155 no ip (but assigned to ports for ASA 'inside' and 'untrusted' IPN only)
VLAN30 10.30.5.250/16 (this is our default vlan right now, I am slowly converting things to VLAN)
so if I understand correctly....
I would eliminate my tunneled route on the ASA....and change my default inside route to point to my core switch IP via the 'work-inside' interface to the CORE VLAN3 SVI IP (10.2.250.3)
no route inside 0.0.0.0 0.0.0.0 10.155.10.11 tunneled
no route inside 10.1.31.0 255.255.255.0 10.155.10.11 1
no route inside 10.1.32.0 255.255.255.0 10.155.10.11 1
no route inside 10.10.0.0 255.255.0.0 10.155.10.11 1
no route inside 10.20.0.0 255.255.0.0 10.155.10.11 1
no route inside 10.30.0.0 255.255.0.0 10.155.10.11 1
no route inside 10.50.0.0 255.255.252.0 10.155.10.11 1
no route inside 10.155.20.0 255.255.255.0 10.155.10.11 1
no route inside 10.201.104.112 255.255.255.240 10.155.10.11 1
no route inside 10.202.104.112 255.255.255.240 10.155.10.11 1
no route inside 172.16.0.0 255.240.0.0 10.155.10.11 1
no route inside 192.168.0.0 255.255.0.0 10.155.10.11 1
route work-inside 0.0.0.0 0.0.0.0 10.2.250.3 (I also have a WAN default route is that correct?)
Then on the IPN:
The CLI only shows a default gateway of 10.30.5.250
so I assume you mean to change the IPN routes through the ISE console
currently the route to the VPN subnet is:
10.154.30.0/24 out the 'untrusted' interface to 10.155.10.10 ('inside' interface of ASA)
needs to be changed to:
10.154.30.0/24 out the 'untrusted' interface to 10.2.250.2 ('work-inside interface of ASA)
On the CORE:
I already have a route for:
ip route 10.154.30.0 255.255.255.0 10.30.5.11 (the 'trusted' interface of the IPN)
So you mention "Create and acl that matches the remote vpn subnet" is this on the ASA or the CORE?
And you mention "Map this to a PBRF and set the next hop to the untrusted interface of the ISE appliance"; I assume since the ASA can't do PBR this is on the CORE?
Am I thinking this through correctly?
You need an ip address on the VLAN 155 so you can set your route-map on that interface. This is where you let the core decide how the site to site traffic is prevented from being routed through the IPN.
So you need to follow the path of all your tunneled packets (using the default route with the tunneled keyword), if you send those packets to the untrusted intrerface you then have to create a subnet filter so that all non client traffic, which in my opinion is not a good design.
Instead I turn up an SVI on the network that the ISE untrusted and the ASA inside both connect on. Then on the core create a route-map so that only client-vpn traffic is routed to the next hop of the IPN untrusted interface. The rest of your questions are dead on.
Let me know if that helps
I just got word that we won't be going live with the FIREWALL portion this weekend as we had planned. Other department issues. So this has bought me some more time.
But I am very happy that I am absorbing this properly.
But, would I still need VLAN155, or would I be better served by removing the 'inside' ASA interface, and make a VLAN for the 'work-inside', CORE SVI, and 'untrusted' IPN interface?
Maybe I'm not getting as well as I thought. I do very much appreciate your replies! VERY helpful.
Hi Dirk, I've read your posts on Cisco Support and Spiceworks regarding this issue. Did you ever get the ASA to work as both the IPN VPN gateway and the internet gateway/firewall?
Please see my reply above.
Also, we are getting ready to move from an IPN based posture, to using the CoA code now in the 9.2+ for ASA. This way we will convert the current IPN to a full fledge ISE node (all services) and keep our current ISE VM (admin, MnT) but convert it to a full ISE node as a failover.
Hoping to get that done by the end of the year.