Using DNS Round Robin and Load Balancers, Front-End Security Applications and Reverse Proxies with SEE Management Server
search cancel

Using DNS Round Robin and Load Balancers, Front-End Security Applications and Reverse Proxies with SEE Management Server

book

Article ID: 193516

calendar_today

Updated On:

Products

Endpoint Encryption Desktop Email Encryption Drive Encryption Encryption Management Server File Share Encryption Gateway Email Encryption Mobile Encryption for iOS PGP Encryption Suite PGP Command Line PGP Key Management Server PGP Key Mgmt Client Access and CLI API PGP SDK

Issue/Introduction

Load Balancers are a valuable and critical part of failover in any network infrastructure and using a Load Balancer with Symantec Endpoint Encryption Management Server (SEEMS) is no exception.  When done properly, this can offer the failover that is needed in order to continue to have clients communicate with the server when one server may not be available.  

When no load balancer is used, but multiple SEE Management Servers are being used, the Symantec Encryption Desktop will enroll to a specific server.  If that server is unavailable, then the clients will no longer be able to download policy or upload logging data to the server, even though there is a cluster.

Symantec Web Email Protection users may not see all their new messages when they log in if one server is not available, even though other nodes are working, so Load Balancers offer a critical part of resilience and availability in a network architecture. 

This article is not intended to be a walkthrough for how to configure a Load Balancer, but will offer some guidance on what you can do to properly configure the Load Balancer so that if one of the SEMS nodes is unavailable, proper failover can occur. 

Cause

Symantec Endpoint Encryption Manager is trying to connect to a server name that does not match the name of the TLS certificate.

In the SEEMS Configuration Manager, in the Web Server section, the Web server name must match the name of the certificate specified in the Server Certificate field.

Resolution

Redundancy for SEE Management Server


It is beneficial to have multiple SEE Management Servers so that you can failover to another node if that particular Windows server goes down.

For example, you may have a server called "seems1.example.com" and another server called "seems2.example.com". 

Each of these servers will be configured with the same database and will share all the same data.  If one server goes down, then the other can be used.

It is important to note that when the SEE Clients are built, they are built using a "Load Balancer" hostname, so the clients will automatically check in with the other nodes.  This means that when you create the SEE client, you will need to have a DNS entry for an alias that will resolve to both "seems1" and "seems2". 

For example, you may have the load balancer host called "seems.example.com", and that host will be resolved to either seems1 or seems2.  If seems1 goes down, the Load Balancer can redirect to "seems2" until seems1 can be brought back up.

Having the TLS certificates configured for "seems.example.com" is critical.  The Load Balancer can then do a TLS termination and simply pass traffic along to the next SEE Management Server. 

Whatever the FQDN is for the SEE Client where it will reach out for server communications, make sure the TLS cert will be resolvable.  If you have SEE Clients that will resolve the host, but the TLS cert has a different name, you may want to consider using a Wildcard Certificate, such as *.example.com.  Then when the SEE Clients reach out to seems.example.com, and are redirected to one of the two SEE Management Servers, the certificate will resolve.

Note: It may also be beneficial to have a "regional" hostname configured so that SEE Clients will always reach out to the closest SEE Management Server.  This is something that could be configured on your own internal network for this resolution to occur within DNS.

Currently the SEE Management Server does not have any automatic failover built in.  If you would like this functionality, reach out to Symantec Encryption Support for further guidance and reference the ID in the Additional Information section below.

ISFR-2443 

 

 

Troubleshooting

Scenario 1: If you are using more than one Symantec Endpoint Encryption Management Server (SEEMS) and you are using a load balancer to distribute the client traffic to the servers, you may find that when you try to run certain commands from Symantec Endpoint Encryption Manager, you receive an SSL/TLS error. For example, you may see the following error message when you  run the Change Web Access Command:

"There was a problem connecting to the server. The underlying connection was closed.  Could not establish trust relationship for the SSL/TLS secure channel."

In the Event Viewer System log you may see a corresponding SChannel error with Event ID 36888:

"A Fatal alert was generated and sent to the remote endpoint.  This may result in termination of the connection.  The TLS protocol defined fatal error code is 70.  The Windows SChannel error state is 105."

 

There are two ways to resolve this.


Option 1 - Modify local hosts file

In SEEMS Configuration Manager, ensure that the Web server name value matches the name of the Symantec Endpoint Encryption Management Server's TLS certificate.

 

For example, suppose that your clients connect to the DNS name see.example.com which resolves to a load balancer that points to two Endpoint Encryption Management Servers with the names see1.example.com and see2.example.com. If the TLS certificate has the name see.example.com then you need to use the name see.example.com as the Web server name in SEEMS Configuration Manager:

You will then need to create an entry in the C:\Windows\System32\drivers\etc\hosts file pointing see.example.com to the IP address of the local Endpoint Encryption Management Server. This is so that each Encryption Management Server resolves the load balancer DNS name to itself.

For example, if the local Endpoint Encryption Management Server has an IP address of 192.168.1.105 the entry would look like this:

192.168.1.105 see.example.com

Option 2 - Use a certificate with additional Subject Alternative Names

If you wish to avoid adding an entry to the local hosts file you can use a TLS certificate that has additional SANs (Subject Alternative Names) for each of the Endpoint Encryption Management Servers. For example, the TLS certificate name is see.example.com but also has SANs for see1.example.com and see2.example.com.

If you obtain a TLS certificate with the correct SANs, SEEMS Configuration Manager can use the Web server name value that matches one of the SANs. For example, see1.example.com.

Additional Information