Troubleshooting External S-TAP Issues

Check for solutions if something goes wrong with your External S-TAPs.

The database connection closes unexpectedly

When External S-TAPs are running, you might encounter an infrequent situation in which the database connection closes unexpectedly. In this case, you need to delete the certificate that is associated with the External S-TAP and restart the External S-TAP, as follows:

  1. Call delete_certificate_external_stap from the Guardium CLI to delete the certificate. This command lists all of the available certificates that are associated with External S-TAPs. Select the number that corresponds to the certificate for the associated External S-TAP®.
  2. Restart the External S-TAP from the UI.

Even without the External S-TAP certificate, the External S-TAP continues to forward traffic to the database.

Database is blocked due to too many connection errors

If your site is using Amazon elastic Kubernetes service (EKS) with Aurora MySQL, you might experience connection errors. In this case, in the Amazon RDS console, set the values for the following instance-level parameters by applying the Parameter Groups to your database instance.

  • max_connect_errors=10000
  • max_connections = 200

Client IP is not correctly recorded for session

Load balancers and proxies can obscure the IP of the client. This behavior is not unique to External S-TAP and multiple methods are available to address this issue. One straight-forward method is to use a load balancer that can inject proxy protocol.

Note: Most databases do not accept proxy protocol themselves and if proxy protocol is enabled, External S-TAP cannot accept sessions without proxy protocol.

If a proxy protocol packet is expected, the packet must exist. Conversely, if a proxy protocol is not expected, the existence of a packet causes the connection to fail.

External S-TAP consumes and removes the proxy protocol packet from the database stream before it sends the session to the backend service.

In AWS, proxy protocol support is available with the classic load balancer. For more information, see the AWS online help on configuring proxy protocol support for the classic load balancer.

Proxy protocol is also supported by many standard load-balancing applications, such as HAProxy, NGINX, or F5 (requires iRules). Set proxy protocol for External S-TAP as follows:
  • From the External S-TAP UI , set Proxy Protocol to 1 - Enabled in the External S-TAP group tab.
  • From the container_mgmt.sh script, specify --proxy-protocol 1.
  • If you deploy External S-TAP with helm, set estap.proxy.proxy_protocol to 1 in the overrides yaml file.
  • If you deploy External S-TAP by using Cloud Pak for Data 3.x, set Proxy protocol expected to 1 in the Database and Proxy tab.

Connection to GIM Server fails

External S-TAP does not use GIM. You can ignore all error messages related to GIM.

Adding users for PostgreSQL 14 and later

Channel binding is enabled by default for PostgreSQL 14 and later. If your site records passwords with Salted Challenge Response Authentication Mechanism (SCRAM), then the server also supports channel binding. To use External S-TAP when channel binding is enabled, set password encryption when you add new users, as follows:

set password_encryption = 'md5'; alter user "username" with password 'newPassword';

Connections resetting with AWS Elastic Load Balancer

In general, you can use AWS network load balancing with External S-TAP (as recommended by AWS). However, if you have issues with the connections resetting, then use the classic elastic load balancer (ELB), which allows you to change the idle session timeout.

For AWS ELB, set the idle session timeout to 4000 seconds.

AWS ELB health check generates misleading connections

By default, the AWS ELB health check uses an available traffic port to connect to the database. These connections can be misinterpreted as suspicious activities. To prevent AWS ELB health check from connecting to the database, set the AWS ELB health check port to 22.

Deploying External S-TAP with AWS fails

To deploy External S-TAP with AWS, IAM user must have the following AWS EKS policies installed:

  • AmazonEKSClusterPolicy
  • AmzonEKSWorkerNodePolicy
  • AdministratorAccess
  • AmzonEKSServicePolicy
  • AmzonEKS_CNI_Policy

Using External S-TAP with a single host

If you use External S-TAP on a Kubernetes cluster that has a single node (which can be the database), then you do not need a load balancing service. Instead of a load balancer, create a NodePort service and set the database connection to use the node hostname and NodePort for monitoring .