Skip links

CA Access Gateway (CAG) on RHEL 8: 503 Error After Installation

This week we have a post about troubleshooting a new CAG 12.8.04 deployment on RHEL 8. As always, we present the reported issue, what we found during troubleshooting, and how the problem was remedied.

IssueCA Access Gateway (CAG) on RHEL 8: 503 Error After Installation
SymptomsWhen attempting to access proxy protected resources, the users would receive an HTTP 503 error (Service Unavailable).
TroubleshootingWe reviewed the server.conf file and did not see any issues with the configuration of the application server. Next, we verified that the server was available and listening on the defined port using the following command: netstat -an | grep 8009. The results of the command showed that the server was indeed listening on that port. We then examined the Apache Tomcat Connector log (mod_jk.log) and searched for any error that would indicate a connection problem with the web application server. The search yielded the following error: “(ajp13) connecting to tomcat failed..)”. We knew that the server was running because of our earlier test and after reviewing the server.log, we found that there were no initialization errors. We ran one additional test; we executed the following command: ping localhost. Although, the server was configured with IPv4 and IPv6 addresses, the ping returned only the IPv6 loopback address of ‘::1’. This meant that the Apache Tomcat web application server was only servicing requests for IPv6.
ConditionThe server was configured with at least one IPv6 address.
CauseThe Apache Tomcat connector uses localhost to connect to the Tomcat web application server, but the CAG was only servicing requests that were IPv6 bound. The server had a host file entry for the IPv6 loopback address for localhost, but it appears that the CAG services do not use it for the Apache Tomcat connector during the configuration.
RemedyWe had the client open the server.conf file in the /opt/CA/secure-proxy/proxy-engine/conf/ directory and then search for the line with ‘worker.ajp13.host=localhost’. We directed them to change this line to ‘worker.ajp13.host=::1’. After a service restart, the requests were routed as expected.

As always, we hope that you have found this information useful. If you need IAM assistance, reach out to SIS today and we would be happy to assist you. And subscribe to our newsletter to be notified about the posting of future articles and other SIS news.

JOIN OUR NEWSLETTER

If you want to know our recent offer please subscribe to our newsletter