When a user tries to connect to VPN using Client, it is successful and there is no problem with it.įor TAC indication, the cluster object main IP has to be set with the private Virtual IP for correct installation of policies between member, sync and logs delivery to the server, etc. In the cluster object, the main IP address is set to be one public IP used for VPN connection. I have it configured as Use Probing HA and both public IP address are set in there. 2 of them are for VPN and Remote Access.Ĭurrently, the Link Selection of the VPN configuration image are in attachments, and there are set up both public addresses used for VPN. I got 4 ISPs link configured for multiple purposes. Engineers may love to hate the 'just edit this file in vi' type of SK, but frankly it's a killer for most endpoint administrators and needs to evolve.I have a culster of 5000 appliances and firmware R80.30. time for EndPoint to grow up a little more and remember that unlike gateways, endpoints are managed by the desktop team where clunky fixes to text files that are not accessible via the management interface are a blocker to acceptability and ultimately to sales success.

These user groups have config needs that are completely different and whilst I can manage a user base with 2 or 3 different faults configurations across around 40 machines, it's clunky and for no good reason.

They have access to customer systems from the VPN, so 2-factor authentication is preferable. But our technical teams need to log on to a completely different VPN gateway, but they are technical and they know when they need a VPN and when they don't. They need to connect if they are out of the office, so I want to give them a sales VPN profile (ideally with transparent machine authentication because they are sales people). One size fits all does not work in large estates.įor example, in our own business - I want my sales team to have an always-on configuration. There is not a simple way to create a VPN policy for these user communities from the central management point, and that seems very strange. In an enterprise estate, there are several user classes (sales, technical, accounts, executives), and these may require different VPN configurations. I have often wondered why, when using the full endpoint management server, that there isn't a better way. The only problem with this approach (and of course it is the prescribed approach) is the unfriendly nature of it.

Check point vpn clients