This information is provided as a 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 failover 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 to 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 using a Load Balancer with Endpoint Prevent
Refer to the About using load balancers in an endpoint deployment Symantec Online Help page.
On this page, there are three Advanced Agent Settings that are important regarding setting up Endpoint Prevent with a Load Balancer.
- EndpointCommunications. IDLE_TIMEOUT_IN_SECONDS.int
These settings are described in more detail on the Advanced agent settings Symantec online Help page.
If resolving based on Fixed hostname 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.
- Refer to Session Persistence Profiles on the F5 website for more information.
- "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.