Best Practices when utilizing multiple network cards in Symantec PAM

Products

• CA Privileged Access Manager (PAM)

Issue/Introduction

Symantec PAM hardware comes with 8 network ports and the virtualized version (currently available on VMWare, AWS and Azure) can also support configuring additional network adapters. Using more than 1 network port can greatly enhance the appliances flexibility in segmented and hardened network environments but adds a level of complexity that may create additional unforeseeable issues from both a product development and customer configuration standpoint.  Additionally, the virtualized networking built into virtualized platforms and VLANs available for traffic shape-ing and network isolation increases the number of variables needed to review or troubleshoot communication between servers and clients. 

Environment

Release : 4.x

Resolution

Symantec PAM appliances are closed appliances so accessing the console to utilize advanced debugging tools or creating custom configuration is not allowed. The best practice for configuring multiple network cards is to keep your configurations as simple as you can based on your specific networking requirements. Essentially, do not simply add additional network cards just because you can.

When configuring a second network card (or bond) this will change several aspects of the default behavior

1.  When configuring a second network to isolate cluster traffic to a separate backend network the use of external load balancers may be required. In 4.x the standard use of the internal load balancer does not take into account client access through our internal VIP. The internal VIP is still used to orchestrate communication within the cluster and must be assigned to the network defined for the cluster itself. In some configurations this is still OK because the client accesses the VIP address and is then pushed to cluster node and will communicate over the default GW of that node. This can be a problem in networks where the backend network is not accessible at all from client access. The best practice in this case is to use an external load balancer to direct client-side traffic to the correct IP for client access.

2. The second network card should not be in the same network segment as the frontend network card. Since the only routing rules provided by GUI are simply in nature you cannot force all communication for the cluster service to only that second network card just by defining it in the cluster configuration. The return traffic for the communication will follow the default GW which would generally not be defined on the backend network. You could possibly create an addition route specific to each cluster appliance which would work but since they are on the same network segment the benefits gained would not be justified by the additional complexity and therefore not a best practice.

3. When configuring A2A and API/CLI access to the PAM appliances it is possible to direct their traffic to any of the configure network cards and defining a specific network for cluster only traffic is not possible as all active network cards will respond to any valid request. The best practice is to use the standard client access address unless there are specific NAT or routing issues with that client that prevent them from communicating with the client.  Both A2A and API/CLI requests are effectively client related activity so generally they should be routed the same. Since any network path not specifically defined in the additional route tables will use the default gateway to respond over the communication in and out would go over the same network interface (this may be important when tracing communications for troubleshooting or for network security tolls review source and destination traffic patterns).

4. Symantec PAM is a proxying device by design, communicating from a PAM Client to the PAM server and then to the Destination Device for many common protocols like RDP and SSH. This makes it a good method to allow client-side access to resources behind a firewall or otherwise inaccessible without a proxy. Using multiple network cards to assign traffic through the PAM appliance is a good practice for this type of access since you can provide a single firewall rule to allow traffic coming from the PAM appliance to these devices. This can be tricky to define rules when there are multiple network paths to those devices so your networking team should be involved in the particulars for name resolution or route definitions required.

5. Using additional network cards to route traffic to and from your recording shares is another good use case where the additional complexity may be worthwhile. NFS and CIFS traffic can impact overloaded client-side networking. Using a backend network for this traffic can reduce congestion and improve overall recording performance. You will most likely require additional routes define in PAM unless already defined for the backend cluster traffic.