Security

Hi Dario

It, depends...
If you are running your ClearPass servers in traditional hardware or virtual appliances you can have VIP addresses. If you have your appliances in a cloud environment such as Azure and AWS the VIP feature isn't supported.

Assuming you have hardware or virtual on-prem installation I normally create one VIP IP address for each server in the cluster and point the client traffic to these VIP addresses instead of the server interface addresses.
Beside the redundancy you get with a VIP the configuration of one VIP per server gives me an easy way of controlling if a server should be able to get the traffic or not.

In case of issues in one ClearPass server it's very convenient to be able to disable this server during troublshooting.
Also hardware replacement in the future will be easier with a VIP configured.

One thing to keep in mind if you have VIP addresses for the servers and are using CX switches with Downloadable User Roles is that the CX switches require the Radius server FDQN to be in the SAN or Subject field of the certificate.
If you have two FDQN, radius1.localdomain.com and radius2.localdomain.com, both of these names must be in the certificates on both servers. I think wildcard certificates should be supported in this scenario, but validate before you put it into  production.

Hi Dario

It, depends...
If you are running your ClearPass servers in traditional hardware or virtual appliances you can have VIP addresses. If you have your appliances in a cloud environment such as Azure and AWS the VIP feature isn't supported.

Assuming you have hardware or virtual on-prem installation I normally create one VIP IP address for each server in the cluster and point the client traffic to these VIP addresses instead of the server interface addresses.
Beside the redundancy you get with a VIP the configuration of one VIP per server gives me an easy way of controlling if a server should be able to get the traffic or not.

In case of issues in one ClearPass server it's very convenient to be able to disable this server during troublshooting.
Also hardware replacement in the future will be easier with a VIP configured.

One thing to keep in mind if you have VIP addresses for the servers and are using CX switches with Downloadable User Roles is that the CX switches require the Radius server FDQN to be in the SAN or Subject field of the certificate.
If you have two FDQN, radius1.localdomain.com and radius2.localdomain.com, both of these names must be in the certificates on both servers. I think wildcard certificates should be supported in this scenario, but validate before you put it into  production.

Hi Dario

It, depends...
If you are running your ClearPass servers in traditional hardware or virtual appliances you can have VIP addresses. If you have your appliances in a cloud environment such as Azure and AWS the VIP feature isn't supported.

Assuming you have hardware or virtual on-prem installation I normally create one VIP IP address for each server in the cluster and point the client traffic to these VIP addresses instead of the server interface addresses.
Beside the redundancy you get with a VIP the configuration of one VIP per server gives me an easy way of controlling if a server should be able to get the traffic or not.

In case of issues in one ClearPass server it's very convenient to be able to disable this server during troublshooting.
Also hardware replacement in the future will be easier with a VIP configured.

One thing to keep in mind if you have VIP addresses for the servers and are using CX switches with Downloadable User Roles is that the CX switches require the Radius server FDQN to be in the SAN or Subject field of the certificate.
If you have two FDQN, radius1.localdomain.com and radius2.localdomain.com, both of these names must be in the certificates on both servers. I think wildcard certificates should be supported in this scenario, but validate before you put it into  production.

I have 1 radius cert that i use across all nodes in a cluster e.g.  radius.sharaz.inf. Also,  i have 1 https cert  with a CN of cppm.sharaz.info and then  SaNs for all the individual nodes in the cluster. Again this cert is used across all cluster nodes.

Havent  implemented DURs on  CX switcehs yet, so just checking, do i have to add  radius.sharaz.info  to the SaN of my  https cert ?

A

Hi Dario

It, depends...
If you are running your ClearPass servers in traditional hardware or virtual appliances you can have VIP addresses. If you have your appliances in a cloud environment such as Azure and AWS the VIP feature isn't supported.

Assuming you have hardware or virtual on-prem installation I normally create one VIP IP address for each server in the cluster and point the client traffic to these VIP addresses instead of the server interface addresses.
Beside the redundancy you get with a VIP the configuration of one VIP per server gives me an easy way of controlling if a server should be able to get the traffic or not.

In case of issues in one ClearPass server it's very convenient to be able to disable this server during troublshooting.
Also hardware replacement in the future will be easier with a VIP configured.

One thing to keep in mind if you have VIP addresses for the servers and are using CX switches with Downloadable User Roles is that the CX switches require the Radius server FDQN to be in the SAN or Subject field of the certificate.
If you have two FDQN, radius1.localdomain.com and radius2.localdomain.com, both of these names must be in the certificates on both servers. I think wildcard certificates should be supported in this scenario, but validate before you put it into  production.

Hi Dario

It, depends...
If you are running your ClearPass servers in traditional hardware or virtual appliances you can have VIP addresses. If you have your appliances in a cloud environment such as Azure and AWS the VIP feature isn't supported.

Assuming you have hardware or virtual on-prem installation I normally create one VIP IP address for each server in the cluster and point the client traffic to these VIP addresses instead of the server interface addresses.
Beside the redundancy you get with a VIP the configuration of one VIP per server gives me an easy way of controlling if a server should be able to get the traffic or not.

In case of issues in one ClearPass server it's very convenient to be able to disable this server during troublshooting.
Also hardware replacement in the future will be easier with a VIP configured.

One thing to keep in mind if you have VIP addresses for the servers and are using CX switches with Downloadable User Roles is that the CX switches require the Radius server FDQN to be in the SAN or Subject field of the certificate.
If you have two FDQN, radius1.localdomain.com and radius2.localdomain.com, both of these names must be in the certificates on both servers. I think wildcard certificates should be supported in this scenario, but validate before you put it into  production.

Hi Dario

It, depends...
If you are running your ClearPass servers in traditional hardware or virtual appliances you can have VIP addresses. If you have your appliances in a cloud environment such as Azure and AWS the VIP feature isn't supported.

Assuming you have hardware or virtual on-prem installation I normally create one VIP IP address for each server in the cluster and point the client traffic to these VIP addresses instead of the server interface addresses.
Beside the redundancy you get with a VIP the configuration of one VIP per server gives me an easy way of controlling if a server should be able to get the traffic or not.

In case of issues in one ClearPass server it's very convenient to be able to disable this server during troublshooting.
Also hardware replacement in the future will be easier with a VIP configured.

One thing to keep in mind if you have VIP addresses for the servers and are using CX switches with Downloadable User Roles is that the CX switches require the Radius server FDQN to be in the SAN or Subject field of the certificate.
If you have two FDQN, radius1.localdomain.com and radius2.localdomain.com, both of these names must be in the certificates on both servers. I think wildcard certificates should be supported in this scenario, but validate before you put it into  production.