Cisco ISE and Microsoft RRAS

[Cloudberry]

Hello community!

I am in the midst of deploying 'Microsoft Always On VPN' and I use 'Microsoft Routing and Remote Access' as a VPN server. I am currently trying to get ISE to authenticate and authorize the user tunnel but I am unable to do this for some reason. The frustrating part about this is that I am unable to spot the connection attempt in the 'RADIUS: live logs'. However performing a TCP dump will render both 'Radius Requests' and 'Radius Challenges' (whereas the latter seem to be ignored by the VPN server).

I see that hits are increasing on the correct rule in the policy set, but no hits on any authentication rule in the policy set - even though I tried a default 'grab everything rule'.

We're doing PEAP (with inner method = User Certificate) and the same PKI is used for other parts of the environment (dot1x e.t.c.).

I've set up a 'Microsoft Network Policy Server' as well and whenever I use that as a RADIUS server the user gets authenticated flawlessly.

Being a 'Cisco fan' I would of course love to use the ISE as the RADIUS server instead of the NPS and I honestly thought it would be an easy operation but for some reason I am having these issues mentioned above. I have been fiddling a bit with the 'Network Device Profile' but I am not sure if the issue really lies here.

Have you guys had any luck with Microsoft Remote Access + Cisco ISE?

Best regards,

Chris

[howon]

If this is production system with lots of authentications, proceed with caution, but I would try disabling suppression under Administration > System > Settings > Protocol > RADIUS. This should provide LiveLog. This will provide visibility into any attempts and provide clue on why ISE is rejecting or ignoring the request.

[Cloudberry]

Yes, this is usually the culprit when I feel that the logs are unfulfilling, however in this particular case I've made sure to uncheck everything.

When I inspect the TCP dumps it looks like the client is ignoring the RADIUS Challenge and just sends another RADIUS Request. Even though we're unsuccessful in reaching a proper authentication/authorization I think we that we should at least see something in the RADIUS live logs where it in worst case scenario is hitting the default rules.

Thank you for helping me look into this.

[hslai]

If the ISE is working for other network devices, then the exchanges between ISE and MS RRAS are likely dying at very early stage so that ISE does not feel it worth of logging.

[Cloudberry]

Yeah, that makes sense, are we suggesting that the problem might lie in the RADIUS Server/Client configuration? I've configured a new 'Network Device Profile' for this Microsoft Server and added the RADIUS dictionary of 'Microsoft' but I've avoided to enable any functions (such as conditions for detecting Wired MAB, CoA e.t.c.)

Do you have any idea on how to troubleshoot this phase of the RADIUS communication?

[Cloudberry]

We have now managed to solve the authentication issues, and it was done by changing the External Identity Source to 'Use Identity From: Certificate Attribute - SAN or Email'.

But the one major problem remains, and that is that we're still unable to see the authentications in the RADIUS Live Logs for this specific setup. Other authentications are visible in the Live Logs.

Is there some sort of 'on/off' logging feature I've missed for this specific Device Group/Device Profile?

[kskksaa]

Hi,

i´m having exactly the same issue - have you found out how to get logging?

Thanks a lot

[Cloudberry · Accepted solution]

Unfortunately not - the policy set is working like a charm (it has over 10k hits by now) but we not yet been able to see any result of this in the Radius Live Logs. If I would perform a packet capture on the ISE I am able to see the exchange however. I am quite unsure what could be the reason behind this.

In any way, I need to patch the nodes & reboot them at any point. If this doesn't solve this problem I will try to consult the TAC.

I'll keep you updated!

[kskksaa]

Hi,

thanks a lot - i guess i also have to investigate this and will keep u also posted. 

Best regards

[kskksaa]

Hi again,

i finally made it to a TAC Case and got it (with limitations) working. 

As soon as we disabled the ISE Messaging Service we were able to see the Always on VPN Logs. But unfortunatly after that we revieved a lot of Accounting Packets in the Live Logs which got interpreted wronf as "Invalid State" 

We are trying to find a solution for that also, but it could be that you do not have this issue because the customer has quite a special deployment with ISE + UNIFI Switches.

[Peter Koltl]

Even if you disable the ISE Messaging Service it is still used for some functions so you should fix (regenerate) the messaging certificates because trust errors are the root cause.