6.5 server heartbeat protocol?

[securitydude]

Does anyone use HTTP instead of ZSPUDP as the heartbeat protocol? Are there any advantages to using HTTP instead of ZSPUDP for the heartbeat?

[CSING]

The advantage of using HTTP is that it is using TCP instead of UDP. Therefore more robust. Also it uses port 80 instead of 6054. Disadvantage is that TCP has a larger network overhead to accomplish the same thing done on UDP. The nice thing with this is that it is a value that can easily be changed from the Server.

[unclerichard]

I am a bit puzzled by the heartbeat process and the authentication by IAS to allow clients to switch over to the connected Enterprise policy. We currently have a configuration where UDP 6054 is blocked by our VPN firewall but we still have the 'majority' (!!!) of clients quite happily switching over to connected policy. Even those that remain on disconnected policy are quite happily heartbeating to the server and the Enterprise policy update time is incrementing on the client even though not active. We have had zspupd set as the heartbeat protocol since the beginning.

Is this the protocol block at fault or is the VPN session-ID fault that was unearthed in HFA05 still present in HFA06 (v199) ??

Unc

[CSING]

"I am a bit puzzled by the heartbeat process and the authentication by IAS to allow clients to switch over to the connected Enterprise policy. We currently have a configuration where UDP 6054 is blocked by our VPN firewall but we still have the 'majority' (!!!) of clients quite happily switching over to connected policy."

Ans. The policy assignment is determined by the sync. request, response and possible download on port 443. So endpoints that can successfully sync will activate the currently connected policy. That is what you are observing.

"Even those that remain on disconnected policy are quite happily heartbeating to the server and the Enterprise policy update time is incrementing on the client even though not active. We have had zspupd set as the heartbeat protocol since the beginning."

Ans. If I assume that endpoints are heartbeating then port 6054 must be open. If these endpoints have the disconnected policy active then I would assume that port 443 is blocked.

Is this the protocol block at fault or is the VPN session-ID fault that was unearthed in HFA05 still present in HFA06 (v199) ??

I don't believe so.

The protocol block is creating unneccessary network traffic and will seriously limit the number endpoints Integrity server can handle. What occurs is that your endpoints sync successfully then tries to hb. When the hb fails, it sync's again. After successfully sync it then tries to hb again which fails. So it syncs again. So instead of sending single udp packets according to your hb interval, you have all your endpoints continously syncing with TCP on port 443 with encryption. Also I would imagine this would greatly hamper loguploads from the client. Do you find that your Reports are totally inaccurate?

HtH

[unclerichard]

(Edited with a clearer description of problem - 19-Feb)

Thanks for the response CSING, it is nice to get a better understanding of what is going on behind the scenes. I have had a bit more info from our VPN guys. The problem with the UDP traffic relates to the Cisco contents switch that we have in front of our Integrity servers. The outgoing UDP from the client gets past the VPN firewall and gets to the IAS. It is the response from the server that gets canned by the VPN firewall as the source address is the actual IAS node IP address rather than that of the switch. Our change will be to dynamically change this source address on the switch.

Many thanks again, will let you know how this goes.

Unc