You need to deploy Symantec Data Loss Prevention (DLP) Endpoint Prevent and need architecture best practice information for the deployment.
You also have the following questions:
Can DNS-based load balancing be used?
Can Endpoint Servers be on different subnets?
Failovers to the original server - what is the nature of this deployment and any considerations for timing or configuration?
Using DNS-based Load Balancing
Servers in DMZ and the internal datacenter
This information is provided as general guide. For support implementing this design please contact professional services.
General Architecture and configuration recommendations:
Here is an example that shows two Endpoint Servers in the corporate LAN and two in the DMZ. Agents on the corporate LAN (including those connected by VPN) are configured to communicate with one of the LAN Endpoint Servers. They are configured to fail over to the second, if necessary. Agents connecting from outside the corporate network are directed to the DMZ Endpoint Servers by a load balancer. All Endpoint Servers are connected to the Enforce Server.
The communication is secured with SSL certificate-based authentication so v12.5+ Endpoint Servers can be deployed in DMZ for Agents to connect over the Internet.
DNAT should be configured to hide the identity of the Endpoint Server.
You don’t need to stick with port 10443. Rather it is better to configure Endpoint Servers to use 443 which is a standard SSL port and is more firewall friendly.
If you decide you want to use a load balancer, it is recommended to enable SSL session affinity.
Give some thought on how you plan to configure the agent for server connectivity. Are you planning to use a single DNS name that gets resolved in the corporate environment and on the Internet?
Be aware that “On/Off” corporate network policy rules are based on Endpoint Server connectivity.
In general, policies should be tuned to reduce false positive detections and to avoid two-tier Detection.
If resolving based on Fixed host name for DNS for DLP Endpoint Prevent
DNS-based Load Balancing can be used.
Based on DNS Load-Balancing implementation, it should be possible for Endpoint Servers to be on different subnets.
For failovers to the original server, the Load-Balancing implementation (e.g., F5, etc.) does the load balancing.
"Source IP persistence" needs to be set on the Load Balancer, e.g., F5. The recommendation is to set this value to 24 hours. Otherwise issues with reporting may be experienced.
Some versions of the F5 do not allow source IP persistence. If this limitation is the case with your Load Balancer, another way to ensure that the endpoints are not “bouncing” between servers should be configured.
"Also known as Simple Persistence, Source Address Affinity Persistence supports TCP and UDP protocols. And directs session requests to the same server based solely on the source IP address of a packet.
The DNS-based load balancing essentially sends agents to their servers in a round-robin fashion: Agent 1 => Server 1, Agent 2 => Server 2, etc. If Server 1 isn't available, Agent 1 goes to Server 2, etc. If all but one Server fails, all Agents connect to the available Server - 3, 4, 5, etc., until previous Servers are back online. After which, DNS again assigns Agent 1, 2, etc., to servers in the available order => Server 1, 2, etc.
Ping times (by Load Balancer like F5) can determine how quickly new connections can go to the newly available servers.
Endpoints have a choice of two Servers (internal vs external), but otherwise, the Load-Balancing implementation (e.g., F5, etc.) does the load balancing.
Subscribing will provide email updates when this Article is updated. Login is required.