Reverse proxy test connection fails

Applications IP Networking
1

I have had a hard time trying to successfully test the connection to a URL from an application server via the reverse proxy. And despite much googling for solutions, I can't seem to find a proper answer.

The application server runs on CentOS 6, and PHP 5.3. The reverse proxy server runs on RHEL 8. It is configured with TLS 1.2 and TLS 1.3, and the ssl.conf includes all the configurations needed for a reverse proxy server.

This is the reverse proxy configuration file in the reverse proxy server :

<VirtualHost _default_:443>
SSLEngine on
# ServerName localhost
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLProxyEngine On
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerExpire off
# ProxyPreserveHost On

ProxyPass /agc https://10.1.1.26/agc acquire=100 retry=0 keepalive=on connectiontimeout=20
ProxyPassReverse /agc https://10.1.1.26/agc

</VirtualHost>

This is the command I use from the app server to test if the connection to the reverse proxy server is successful :

[root@agrotestapp ~]# curl https://10.1.3.90/agc:443 -v https://10.1.1.26/agc
* About to connect() to proxy 10.1.3.90 port 443 (#0)
* Trying 10.1.3.90... connected
* Connected to 10.1.3.90 (10.1.3.90) port 443 (#0)
* Establish HTTP proxy tunnel to 10.1.3.90:443
* Proxy auth using Basic with user 'jadmin'
> CONNECT 10.1.3.90:443 HTTP/1.1
> Host: 10.1.3.90:443
> Proxy-Authorization: Basic amFkbWluOmdyZWF0RGF5cw==
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.44 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Proxy-Connection: Keep-Alive
>
* Proxy CONNECT aborted
* Closing connection #0
curl: (56) Proxy CONNECT aborted
* About to connect() to proxy 10.1.3.90 port 443 (#0)
* Trying 10.1.3.90... connected
* Connected to 10.1.3.90 (10.1.3.90) port 443 (#0)
* Establish HTTP proxy tunnel to 10.1.1.26:443
* Proxy auth using Basic with user 'jadmin'
> CONNECT 10.1.1.26:443 HTTP/1.1
> Host: 10.1.1.26:443
> Proxy-Authorization: Basic amFkbWluOmdyZWF0RGF5cw==
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.44 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Proxy-Connection: Keep-Alive
>
* Proxy CONNECT aborted
* Closing connection #0
curl: (56) Proxy CONNECT aborted

As you can see, it exits with the curl: (56) Proxy CONNECT aborted error.

Some of the solutions I googled mentioned something about ensuring that SSL cert and keys configured and installed. Others mentioned to ensure that the port number used to curl is correct. The latter is correct for me, but I am not sure if the SSL cert and key solution is correct.

Additionally, these were the error in the logs :

[Fri May 24 18:34:53.804143 2024] [core:notice] [pid 31243:tid 140054901700928] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Fri May 24 18:34:53.804953 2024] [suexec:notice] [pid 31243:tid 140054901700928] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Fri May 24 18:34:53.805936 2024] [ssl:warn] [pid 31243:tid 140054901700928] AH01909: localhost:443:0 server certificate does NOT include an ID which matches the server name
[Fri May 24 18:34:53.823249 2024] [ssl:warn] [pid 31243:tid 140054901700928] AH01909: localhost:443:0 server certificate does NOT include an ID which matches the server name
[Fri May 24 18:34:53.823556 2024] [lbmethod_heartbeat:notice] [pid 31243:tid 140054901700928] AH02282: No slotmem from mod_heartmonitor
[Fri May 24 18:34:53.826286 2024] [mpm_event:notice] [pid 31243:tid 140054901700928] AH00489: Apache/2.4.37 (Oracle Linux) OpenSSL/1.1.1k configured -- resuming normal operations
[Fri May 24 18:34:53.826306 2024] [core:notice] [pid 31243:tid 140054901700928] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'

However even when I run setenforce 0, and SELinux is permissive, I still get the same error. I consulted my teammates first about the server hostname does not match name in certificate error, but they don't even use that parameter.

Please guide to fix this issue, and let me know if you need any other information to aid with troubleshooting.

2

Hi @aigini82,

I'm confused as to why you're having curl use a proxy at all.

When I've used reverse proxies / application accelerators like this many times in the past, clients connecting to the reverse proxy / application accelerator have no idea that they are connecting to a proxy. The applications simply request the URL that they want and the proxy recognizes that the requested URL is part of the ProxyPass / ProxyPassReverse and automatically proxies the traffic on behalf of and without the client's knowledge that it's doing so.

Since curl is trying to use 10.1.3.90 as an active proxy server, I'm going to assume that there is an environment variable / configuration that is causing curl to do so as I'm not recognizing anything in the command line that would cause it to do so.

I would suggest that you try causing curl to not use 10.1.3.90 as a forward proxy.

I'd also test this by speaking HTTP directly to 10.1.3.90 using OpenSSL's openssl s_client command to connect to 10.1.3.90 using HTTPS and then ask for the https://10.1.1.26/agc page.

$ openssl s_client -connect 10.1.3.90 443
GET /agc HTTP/1.0
Host: 10.1.1.26

My syntax might not be exactly correct, but I think it'll get you in the ball park.

3

Ok, so does this mean I do not have to worry about the curl(56) PROXY connection aborted error, or I am using curl in a wrong way? I am not sure why, but my teammates use curl to test out the proxy connectivity, but seems like they cannot explain to me why they use the method and how to fix problems like this.

4

It turned out that I had an existing proxy config in my server, which I thought I had eliminated, but apparently it was cached, so it didn't go away from the environment variables. I had to manually run the command below to remove it, and this fixed the problem.

export https_proxy=
export http_proxy=

5

Proxies can be used in two directions:

  • forward - client out to the world
  • reverse - world into a server

Clients need some sort of configuration to use a proxy in the forward direction.

Clients don't need any configuration to use a reverse proxy as to the client, the proxy is the destination server.

Using these two directions together can get quite tricky.

6

That makes perfect sense from what I was seeing.

N.B. you may need this configuration to access the internet in a forward proxy configuration.

I believe this was interfering with things in the reverse proxy configuration.