Chapter 7. Networking


Resolve networking issues including subnet conflicts and SSL/TLS certificate problems.

The default subnet used in Ansible Automation Platform containers conflicts with the internal network resulting in "No route to host" errors.

To resolve this issue, update the default classless inter-domain routing (CIDR) value so it does not conflict with the CIDR used by the default Podman networking plugin.

Procedure

  1. In all controller and hybrid nodes, run the following commands to create a file called custom.py:

    # touch /etc/tower/conf.d/custom.py
    # chmod 640 /etc/tower/conf.d/custom.py
    # chown root:awx /etc/tower/conf.d/custom.py
  2. Add the following to the /etc/tower/conf.d/custom.py file:

    DEFAULT_CONTAINER_RUN_OPTIONS = ['--network', 'slirp4netns:enable_ipv6=true,cidr=192.168.1.0/24']
    • 192.168.1.0/24 is the value for the new CIDR in this example.
  3. Stop and start the automation controller service in all controller and hybrid nodes:

    # automation-controller-service stop
    # automation-controller-service start

    All containers will start on the new CIDR.

7.2. Troubleshooting SSL/TLS issues

To troubleshoot SSL/TLS issues, verify the certificate chain, use the correct certificates, and confirm that a trusted Certificate Authority (CA) signed the certificate.

Procedure

  1. Check if the server is reachable over SSL/TLS.

    1. Run the following command to confirm whether the server is reachable over SSL/TLS and to see the full certificate chain:

      # true | openssl s_client -showcerts -connect <fqdn_or_ip>:<port>
    2. Replace <fqdn_or_ip> and <port> with suitable values.
  2. Verify the certificate details.

    1. Run the following command to view the details of a certificate:

      # openssl x509 -in <path_to_certificate> -noout -text
  3. Replace <path_to_certificate> with the path to the certificate file you want to inspect.

    The result of the command shows information such as:

    • Subject - The entity the certificate has been issued to.
    • Issuer - The CA that issued the certificate.
    • Validity "Not Before" - The date the certificate was issued.
    • Validity "Not After" - The date the certificate expires.
  4. Verify a trusted CA signed the certificate.

    1. Run the following command to verify that a specific certificate is valid and was signed by a trusted CA:

      openssl verify -CAfile <path_to_ca_public_certificate> <path_to_server_certificate_file_to_verify>
    2. If the command returns OK, it means the certificate file is valid and signed by a trusted CA.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top