Security

Good morning all, 

 

Working with a customer on an OnGuard wired deployment with Cisco switches, but having some trouble. So we are pushing the OnGuard Persistent Agent out to all domain machines to verify health. However, it's possible a  user doesn't get the agent or connects with non-domain device. We want them to still get access if their healthy. 

 

We currently have CPPM configured to recognize health, if healthy then VLAN 104, if quarantined then VLAN 444, if unknown VLAN 104 w/ redirect ACL. When we have an unknown client (even with OnGuard agent installed), we see the initial authentication (unknown health), then the health check appears to take place and see's them as healthy, but we never have a re-authentication. Normally I would say it's a COA issue, but COA works when we manually try it or disable the redirect ACL. It appears that Onguard completes all connections except the control channel communication, which points me toward the port 25427 for backend communication, but not sure if it's the root issue. Again, this works flawlessly without the redirect ACL.

 

Anybody have any ideas?

 

Thanks.

You need to allow TCP 6658 from the clients to ClearPass.

I'm trying to get a copy of our ACL to show what we currently have, but we have:

 

deny dns

deny ip <clearpass IP>

deny 6658 <clearpas IP>

allow http <clearpass IP>

allow https <clearpass IP>

 

For the redirect, I was informed that you have to deny everything you want access to, and allow what you want to be redirected. Hopefully that sounds right. Should we also add a statement about 25427?

I just added port 25427 to the ACL. Currently it looks like:

 

Extended IP access list ACL-WEBAUTH-REDIRECT
10 deny udp any any eq domain (3107 matches)
20 deny tcp any any eq domain (66 matches)
23 deny tcp any any eq 6658
25 deny tcp any any eq 25427
30 deny ip any host 172.19.201.30

40 deny ip any host 172.19.201.31
50 permit tcp any any eq www (828100 matches)
60 permit tcp any any eq 443 (91212 matches)

 

172.19.201.30 is a virtual interface on F5, which load-balances the RADIUS traffic to ClearPass, while 172.19.201.31 is a virtual interface on F5, which load-balances web traffic to ClearPass.

 

Haven't tested this yet, but any foreseeable problems with the way this is setup?

25427 is only used locally on the host. There is no external communication
using that port.



Are you using a dACL or a local ACL on the switch?

Oh, didn't know that. Why would the control channel not establish a connection when running a diagnostic test? I thought maybe it was being blocked on the network. It's a ACL on the switch

We were able to identify the issue - 

 

So in the backend logs, it appeared that clearpass was not reachable. So we initially saw our wired authentication, but no health check. Turned out to be an issue with our ACL.

 

When using an F5 appliance to load-balance, the authentication goes to what ever server it chooses, however, the health check ALWAYS goes directly to the publisher (at least in our case), and bypasses the VIP on the F5. We were only allowing access to the VIP address and not the actual publisher's address. Added it to the ACL and it established successfully and all checks worked perfectly.  We also added the standby publisher's address in case of a fail over.

 

I will definitely retain this for next time. Thanks for everyone's help!