Security

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?

1. "May work" vs "supported requirements".  Always go with what is called out as the supported requirements.
2. VIP should really only ever be used for HTTP/HTTPS services...and even some of those situations still only work when communicating with the Publisher.  VIP is there for redundancy if you don't have a load balancer.  Never use the VIP for RADIUS or TACACS+.
3. VIP failover is dependent on the heartbeat, publisher failover is entirely independent of any configured VIPs or their operation.  Publisher failover happens when the standby publisher cannot communicate with the publisher for the configured amount of time.

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?

Hi.

Herman's intent with two VIP is as follows. 

1. You configure a VIP for each Clearpass server and it's backup. Server 1 VIP1 (primary server 1, backup server 2), and same for Server 2 (primary server 2 and backup server 1).
2. Configure RADIUS servers on switches and other devices by using those VIP addresses. Use both VIPs in configuration. Business as usual.
3. If one clearpass server fails it's VIP will be moved to second server. Sessions authenticated by failed server will still be able to communicate with RADIUS as IP will not change and these sessions know only old IP. If you use a server's IP, then those sessions need to reauthenticate with new RADIUS server. I believe there is also COA communication still possible as old IP is reachable even if old server is down.

 I think that Herman explained this in his video.

Best, Gorazd

1. "May work" vs "supported requirements".  Always go with what is called out as the supported requirements.
2. VIP should really only ever be used for HTTP/HTTPS services...and even some of those situations still only work when communicating with the Publisher.  VIP is there for redundancy if you don't have a load balancer.  Never use the VIP for RADIUS or TACACS+.
3. VIP failover is dependent on the heartbeat, publisher failover is entirely independent of any configured VIPs or their operation.  Publisher failover happens when the standby publisher cannot communicate with the publisher for the configured amount of time.

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?

Please never use the VIP for RADIUS or TACACS+.  Create the server entries, create a server group that contains all relevant servers, allow the NAD to determine dead servers and implement the dead time.  This also allows products that have an internal load balancing implementation to do so.  Using the VIP inevitably leads to someone overloading a single node.

Dynamic authorization is sent by the ClearPass node.  Would have to validate that ClearPass sources the outbound DynAuth communication using the VIP address.

Hi.

Herman's intent with two VIP is as follows. 

1. You configure a VIP for each Clearpass server and it's backup. Server 1 VIP1 (primary server 1, backup server 2), and same for Server 2 (primary server 2 and backup server 1).
2. Configure RADIUS servers on switches and other devices by using those VIP addresses. Use both VIPs in configuration. Business as usual.
3. If one clearpass server fails it's VIP will be moved to second server. Sessions authenticated by failed server will still be able to communicate with RADIUS as IP will not change and these sessions know only old IP. If you use a server's IP, then those sessions need to reauthenticate with new RADIUS server. I believe there is also COA communication still possible as old IP is reachable even if old server is down.

 I think that Herman explained this in his video.

Best, Gorazd

1. "May work" vs "supported requirements".  Always go with what is called out as the supported requirements.
2. VIP should really only ever be used for HTTP/HTTPS services...and even some of those situations still only work when communicating with the Publisher.  VIP is there for redundancy if you don't have a load balancer.  Never use the VIP for RADIUS or TACACS+.
3. VIP failover is dependent on the heartbeat, publisher failover is entirely independent of any configured VIPs or their operation.  Publisher failover happens when the standby publisher cannot communicate with the publisher for the configured amount of time.

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?

Please never use the VIP for RADIUS or TACACS+.  Create the server entries, create a server group that contains all relevant servers, allow the NAD to determine dead servers and implement the dead time.  This also allows products that have an internal load balancing implementation to do so.  Using the VIP inevitably leads to someone overloading a single node.

Dynamic authorization is sent by the ClearPass node.  Would have to validate that ClearPass sources the outbound DynAuth communication using the VIP address.

Hi.

Herman's intent with two VIP is as follows. 

1. You configure a VIP for each Clearpass server and it's backup. Server 1 VIP1 (primary server 1, backup server 2), and same for Server 2 (primary server 2 and backup server 1).
2. Configure RADIUS servers on switches and other devices by using those VIP addresses. Use both VIPs in configuration. Business as usual.
3. If one clearpass server fails it's VIP will be moved to second server. Sessions authenticated by failed server will still be able to communicate with RADIUS as IP will not change and these sessions know only old IP. If you use a server's IP, then those sessions need to reauthenticate with new RADIUS server. I believe there is also COA communication still possible as old IP is reachable even if old server is down.

 I think that Herman explained this in his video.

Best, Gorazd

1. "May work" vs "supported requirements".  Always go with what is called out as the supported requirements.
2. VIP should really only ever be used for HTTP/HTTPS services...and even some of those situations still only work when communicating with the Publisher.  VIP is there for redundancy if you don't have a load balancer.  Never use the VIP for RADIUS or TACACS+.
3. VIP failover is dependent on the heartbeat, publisher failover is entirely independent of any configured VIPs or their operation.  Publisher failover happens when the standby publisher cannot communicate with the publisher for the configured amount of time.

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?

Hi.

Herman's intent with two VIP is as follows. 

1. You configure a VIP for each Clearpass server and it's backup. Server 1 VIP1 (primary server 1, backup server 2), and same for Server 2 (primary server 2 and backup server 1).
2. Configure RADIUS servers on switches and other devices by using those VIP addresses. Use both VIPs in configuration. Business as usual.
3. If one clearpass server fails it's VIP will be moved to second server. Sessions authenticated by failed server will still be able to communicate with RADIUS as IP will not change and these sessions know only old IP. If you use a server's IP, then those sessions need to reauthenticate with new RADIUS server. I believe there is also COA communication still possible as old IP is reachable even if old server is down.

 I think that Herman explained this in his video.

Best, Gorazd

1. "May work" vs "supported requirements".  Always go with what is called out as the supported requirements.
2. VIP should really only ever be used for HTTP/HTTPS services...and even some of those situations still only work when communicating with the Publisher.  VIP is there for redundancy if you don't have a load balancer.  Never use the VIP for RADIUS or TACACS+.
3. VIP failover is dependent on the heartbeat, publisher failover is entirely independent of any configured VIPs or their operation.  Publisher failover happens when the standby publisher cannot communicate with the publisher for the configured amount of time.

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?

He described the basic failover concept, which is fine. I get how VRRP works.  Application load balancing is never that simple though. Depending on session state on each server and how those servers reconcile that discrepancy is always the part nobody can see because it is buried in the code.

It sounds like you are saying that session state built to a VIP will follow that VIP to the other node?  That does sound like a big benefit. Do you know if anyone has enumerated the multitude of cases where Clearpass nodes in a cluster truly function as a cluster and can take over session functions for the other vs operating as independent nodes and the failover is a disruptive switch to the other node by the client?

Similarly, even if a subscriber is taking the load, doesn't the publisher still have to perform the writes on the database?  ie loss of a publish essentially makes the subscribers useless until the timer runs out and the backup subscriber takes over?

Hi.

Herman's intent with two VIP is as follows. 

1. You configure a VIP for each Clearpass server and it's backup. Server 1 VIP1 (primary server 1, backup server 2), and same for Server 2 (primary server 2 and backup server 1).
2. Configure RADIUS servers on switches and other devices by using those VIP addresses. Use both VIPs in configuration. Business as usual.
3. If one clearpass server fails it's VIP will be moved to second server. Sessions authenticated by failed server will still be able to communicate with RADIUS as IP will not change and these sessions know only old IP. If you use a server's IP, then those sessions need to reauthenticate with new RADIUS server. I believe there is also COA communication still possible as old IP is reachable even if old server is down.

 I think that Herman explained this in his video.

Best, Gorazd

1. "May work" vs "supported requirements".  Always go with what is called out as the supported requirements.
2. VIP should really only ever be used for HTTP/HTTPS services...and even some of those situations still only work when communicating with the Publisher.  VIP is there for redundancy if you don't have a load balancer.  Never use the VIP for RADIUS or TACACS+.
3. VIP failover is dependent on the heartbeat, publisher failover is entirely independent of any configured VIPs or their operation.  Publisher failover happens when the standby publisher cannot communicate with the publisher for the configured amount of time.

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?

No...not saying anything about the session state being brought over.  This is VRRP level functionality, moving the IP address from one box to the other.

The subscriber can operate mostly independent of the publisher for up to ~24 hours before the cluster connection will be permanently out of sync and require the node to be dropped and re-added to the cluster when the publisher is back online.

The most important functionality lost when operating without a publisher is new accounts. The usual examples:

• New guest accounts have to be synchronized by the publisher so that all subscribers have the record.
• Guest accounts requiring sponsorship have to be done through the publisher.
• Onboard maintains the CA environment on the publisher.

The VIP is useful for HTTP/HTTPS failover for smaller captive portal environments where the usage isn't going to overwhelm any single node.  The VIP tends to be useful for operations that must go against the publisher, by either setting a failover with the standby publisher or allowing the reassignment of the VIP to another node should the publisher not be available.

He described the basic failover concept, which is fine. I get how VRRP works.  Application load balancing is never that simple though. Depending on session state on each server and how those servers reconcile that discrepancy is always the part nobody can see because it is buried in the code.

It sounds like you are saying that session state built to a VIP will follow that VIP to the other node?  That does sound like a big benefit. Do you know if anyone has enumerated the multitude of cases where Clearpass nodes in a cluster truly function as a cluster and can take over session functions for the other vs operating as independent nodes and the failover is a disruptive switch to the other node by the client?

Similarly, even if a subscriber is taking the load, doesn't the publisher still have to perform the writes on the database?  ie loss of a publish essentially makes the subscribers useless until the timer runs out and the backup subscriber takes over?

Hi.

Herman's intent with two VIP is as follows. 

1. You configure a VIP for each Clearpass server and it's backup. Server 1 VIP1 (primary server 1, backup server 2), and same for Server 2 (primary server 2 and backup server 1).
2. Configure RADIUS servers on switches and other devices by using those VIP addresses. Use both VIPs in configuration. Business as usual.
3. If one clearpass server fails it's VIP will be moved to second server. Sessions authenticated by failed server will still be able to communicate with RADIUS as IP will not change and these sessions know only old IP. If you use a server's IP, then those sessions need to reauthenticate with new RADIUS server. I believe there is also COA communication still possible as old IP is reachable even if old server is down.

 I think that Herman explained this in his video.

Best, Gorazd

1. "May work" vs "supported requirements".  Always go with what is called out as the supported requirements.
2. VIP should really only ever be used for HTTP/HTTPS services...and even some of those situations still only work when communicating with the Publisher.  VIP is there for redundancy if you don't have a load balancer.  Never use the VIP for RADIUS or TACACS+.
3. VIP failover is dependent on the heartbeat, publisher failover is entirely independent of any configured VIPs or their operation.  Publisher failover happens when the standby publisher cannot communicate with the publisher for the configured amount of time.

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?

No...not saying anything about the session state being brought over.  This is VRRP level functionality, moving the IP address from one box to the other.

The subscriber can operate mostly independent of the publisher for up to ~24 hours before the cluster connection will be permanently out of sync and require the node to be dropped and re-added to the cluster when the publisher is back online.

The most important functionality lost when operating without a publisher is new accounts. The usual examples:

• New guest accounts have to be synchronized by the publisher so that all subscribers have the record.
• Guest accounts requiring sponsorship have to be done through the publisher.
• Onboard maintains the CA environment on the publisher.

The VIP is useful for HTTP/HTTPS failover for smaller captive portal environments where the usage isn't going to overwhelm any single node.  The VIP tends to be useful for operations that must go against the publisher, by either setting a failover with the standby publisher or allowing the reassignment of the VIP to another node should the publisher not be available.

He described the basic failover concept, which is fine. I get how VRRP works.  Application load balancing is never that simple though. Depending on session state on each server and how those servers reconcile that discrepancy is always the part nobody can see because it is buried in the code.

It sounds like you are saying that session state built to a VIP will follow that VIP to the other node?  That does sound like a big benefit. Do you know if anyone has enumerated the multitude of cases where Clearpass nodes in a cluster truly function as a cluster and can take over session functions for the other vs operating as independent nodes and the failover is a disruptive switch to the other node by the client?

Similarly, even if a subscriber is taking the load, doesn't the publisher still have to perform the writes on the database?  ie loss of a publish essentially makes the subscribers useless until the timer runs out and the backup subscriber takes over?

Hi.

Herman's intent with two VIP is as follows. 

1. You configure a VIP for each Clearpass server and it's backup. Server 1 VIP1 (primary server 1, backup server 2), and same for Server 2 (primary server 2 and backup server 1).
2. Configure RADIUS servers on switches and other devices by using those VIP addresses. Use both VIPs in configuration. Business as usual.
3. If one clearpass server fails it's VIP will be moved to second server. Sessions authenticated by failed server will still be able to communicate with RADIUS as IP will not change and these sessions know only old IP. If you use a server's IP, then those sessions need to reauthenticate with new RADIUS server. I believe there is also COA communication still possible as old IP is reachable even if old server is down.

 I think that Herman explained this in his video.

Best, Gorazd

1. "May work" vs "supported requirements".  Always go with what is called out as the supported requirements.
2. VIP should really only ever be used for HTTP/HTTPS services...and even some of those situations still only work when communicating with the Publisher.  VIP is there for redundancy if you don't have a load balancer.  Never use the VIP for RADIUS or TACACS+.
3. VIP failover is dependent on the heartbeat, publisher failover is entirely independent of any configured VIPs or their operation.  Publisher failover happens when the standby publisher cannot communicate with the publisher for the configured amount of time.

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?

No...not saying anything about the session state being brought over.  This is VRRP level functionality, moving the IP address from one box to the other.

The subscriber can operate mostly independent of the publisher for up to ~24 hours before the cluster connection will be permanently out of sync and require the node to be dropped and re-added to the cluster when the publisher is back online.

The most important functionality lost when operating without a publisher is new accounts. The usual examples:

• New guest accounts have to be synchronized by the publisher so that all subscribers have the record.
• Guest accounts requiring sponsorship have to be done through the publisher.
• Onboard maintains the CA environment on the publisher.

The VIP is useful for HTTP/HTTPS failover for smaller captive portal environments where the usage isn't going to overwhelm any single node.  The VIP tends to be useful for operations that must go against the publisher, by either setting a failover with the standby publisher or allowing the reassignment of the VIP to another node should the publisher not be available.

He described the basic failover concept, which is fine. I get how VRRP works.  Application load balancing is never that simple though. Depending on session state on each server and how those servers reconcile that discrepancy is always the part nobody can see because it is buried in the code.

It sounds like you are saying that session state built to a VIP will follow that VIP to the other node?  That does sound like a big benefit. Do you know if anyone has enumerated the multitude of cases where Clearpass nodes in a cluster truly function as a cluster and can take over session functions for the other vs operating as independent nodes and the failover is a disruptive switch to the other node by the client?

Similarly, even if a subscriber is taking the load, doesn't the publisher still have to perform the writes on the database?  ie loss of a publish essentially makes the subscribers useless until the timer runs out and the backup subscriber takes over?

Hi.

Herman's intent with two VIP is as follows. 

1. You configure a VIP for each Clearpass server and it's backup. Server 1 VIP1 (primary server 1, backup server 2), and same for Server 2 (primary server 2 and backup server 1).
2. Configure RADIUS servers on switches and other devices by using those VIP addresses. Use both VIPs in configuration. Business as usual.
3. If one clearpass server fails it's VIP will be moved to second server. Sessions authenticated by failed server will still be able to communicate with RADIUS as IP will not change and these sessions know only old IP. If you use a server's IP, then those sessions need to reauthenticate with new RADIUS server. I believe there is also COA communication still possible as old IP is reachable even if old server is down.

 I think that Herman explained this in his video.

Best, Gorazd

1. "May work" vs "supported requirements".  Always go with what is called out as the supported requirements.
2. VIP should really only ever be used for HTTP/HTTPS services...and even some of those situations still only work when communicating with the Publisher.  VIP is there for redundancy if you don't have a load balancer.  Never use the VIP for RADIUS or TACACS+.
3. VIP failover is dependent on the heartbeat, publisher failover is entirely independent of any configured VIPs or their operation.  Publisher failover happens when the standby publisher cannot communicate with the publisher for the configured amount of time.

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?

The cluster and cluster operations is separate from the VIP operation except that only cluster members can be chosen as options for the VIP.

Correct.

The only automatic move of the publisher function is by using standby publisher failover.  If the standby failover operation happens, there is a relatively graceful way to bring the previous publisher node back into the cluster and then instruct the move of the publisher functionality back to the original node.  Note, the previous publisher will not immediately start operating in the cluster without admin intervention.

No...not saying anything about the session state being brought over.  This is VRRP level functionality, moving the IP address from one box to the other.

The subscriber can operate mostly independent of the publisher for up to ~24 hours before the cluster connection will be permanently out of sync and require the node to be dropped and re-added to the cluster when the publisher is back online.

The most important functionality lost when operating without a publisher is new accounts. The usual examples:

• New guest accounts have to be synchronized by the publisher so that all subscribers have the record.
• Guest accounts requiring sponsorship have to be done through the publisher.
• Onboard maintains the CA environment on the publisher.

The VIP is useful for HTTP/HTTPS failover for smaller captive portal environments where the usage isn't going to overwhelm any single node.  The VIP tends to be useful for operations that must go against the publisher, by either setting a failover with the standby publisher or allowing the reassignment of the VIP to another node should the publisher not be available.

He described the basic failover concept, which is fine. I get how VRRP works.  Application load balancing is never that simple though. Depending on session state on each server and how those servers reconcile that discrepancy is always the part nobody can see because it is buried in the code.

It sounds like you are saying that session state built to a VIP will follow that VIP to the other node?  That does sound like a big benefit. Do you know if anyone has enumerated the multitude of cases where Clearpass nodes in a cluster truly function as a cluster and can take over session functions for the other vs operating as independent nodes and the failover is a disruptive switch to the other node by the client?

Similarly, even if a subscriber is taking the load, doesn't the publisher still have to perform the writes on the database?  ie loss of a publish essentially makes the subscribers useless until the timer runs out and the backup subscriber takes over?

Hi.

Herman's intent with two VIP is as follows. 

1. You configure a VIP for each Clearpass server and it's backup. Server 1 VIP1 (primary server 1, backup server 2), and same for Server 2 (primary server 2 and backup server 1).
2. Configure RADIUS servers on switches and other devices by using those VIP addresses. Use both VIPs in configuration. Business as usual.
3. If one clearpass server fails it's VIP will be moved to second server. Sessions authenticated by failed server will still be able to communicate with RADIUS as IP will not change and these sessions know only old IP. If you use a server's IP, then those sessions need to reauthenticate with new RADIUS server. I believe there is also COA communication still possible as old IP is reachable even if old server is down.

 I think that Herman explained this in his video.

Best, Gorazd

1. "May work" vs "supported requirements".  Always go with what is called out as the supported requirements.
2. VIP should really only ever be used for HTTP/HTTPS services...and even some of those situations still only work when communicating with the Publisher.  VIP is there for redundancy if you don't have a load balancer.  Never use the VIP for RADIUS or TACACS+.
3. VIP failover is dependent on the heartbeat, publisher failover is entirely independent of any configured VIPs or their operation.  Publisher failover happens when the standby publisher cannot communicate with the publisher for the configured amount of time.

I am currently reviewing my install of Clearpass and am considering making some changes.

1. I am using a VIP on my cluster, however, the docs say I need to accept forged packets in VMware, yet mine is working and that is currently set to reject. Did something change along the way that will allow VIPs to work without allowing forged packets in the VMware port group?
2. I saw a tutorial of Herman's where he setup two VIPs and reversed the primary node on each.  Is the idea to speed up failover in the event of failure instead of waiting on the switch or AP to timeout on the first radius server and try the second?  I don't quite understand the motivation for having VIPs for radius in addition to redundant radius servers on the radius clients...
3. Somewhat related to the previous question..VIP failover is independent of publisher role failover isn't it?