Category: Uncategorized

As mentioned in a previous post, I recently heard about a case where someone wanted to allow an AWS EC2 instance on a public IP address to access a corporate intranet resource. The proposed solution was to run an HAProxy server on the corporate network that could proxy traffic from the AWS compute instance to the intranet server. This post will give a demonstration of that.

Please note: Don’t bypass your organization’s security controls! Implementing a solution like this without prior authorization or approval would likely constitute a violation of an organization’s acceptable use policy or information security policies.

The 3 servers for this example:

1. The corporate intranet resource, intranet.osric.net or 192.0.2.43
2. The HAProxy host, haproxy.osric.net or 198.51.100.200
3. The AWS EC2 instance, ec2-203-0-113-155.compute-1.amazonaws.com or 203.0.113.155

Although I’ve primarily used HAProxy for load balancing in the past, it can easily be used as a basic reverse proxy server. A load-balancer, after all, is basically a reverse proxy with multiple backend servers. I set up a new RedHat Enterprise Linux (RHEL) 10 host, haproxy.osric.net and installed and enabled HAProxy:

$ sudo dnf install haproxy
$ sudo systemctl enable haproxy

I then added an HAProxy config at /etc/haproxy/conf.d/proxy.cfg HAProxy should automatically find a config file ending with .cfg at that location. The default config included at /etc/haproxy/haproxy.cfg will also be loaded. It includes some config options you won’t need!

Here is the content I added to proxy.cfg:

listen http-proxy
    bind :80
    server intranet 192.0.2.43:80

I restarted the haproxy service:

$ sudo systemctl restart haproxy

After that I was able to use curl to access the intranet resource, both from the haproxy host and from the EC2 instance:

From the haproxy host:

$ curl localhost
<!DOCTYPE html>
<html>
<head>
<title>Intranet - osric.net</title>
</head>
<body>
<h1>Intranet - osric.net</h1>
<p>There is nothing to see here.</p>
</body>
</html>

From 203.0.113.155 (the AWS EC2 instance):

$ curl 198.51.100.200
<!DOCTYPE html>
<html>
<head>
<title>Intranet - osric.net</title>
</head>
<body>
<h1>Intranet - osric.net</h1>
<p>There is nothing to see here.</p>
</body>
</html>

Restricting proxy access

As it is, the proxy is open to the world. Anyone can now access resources from intranet.osric.net via the proxy. How can we lock it down so that only the intended IP address, 203.0.113.155, can access it?

I found the article Allow and Block IP Addresses in HAProxy (2026) with some tips. I modified the proxy.cfg file:

$ cat /etc/haproxy/conf.d/proxy.cfg
listen http-proxy
    bind :80
    acl authorized_ip src 203.0.113.155
    http-request deny if !authorized_ip
    server intranet 192.0.2.43:80

From the HAProxy server the HTTP request is denied by HAProxy with an HTTP 403 error:

$ curl localhost
<html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>

However, the request still works from the IP address of the authorized AWS EC2 instance:

$ curl 198.51.100.200
<!DOCTYPE html>
<html>
<head>
<title>Intranet - osric.net</title>
</head>
<body>
<h1>Intranet - osric.net</h1>
<p>There is nothing to see here.</p>
</body>
</html>

Host-based firewall restrictions

It’s best if HAProxy never even sees the request from unauthorized sources. We can achieve this by allowing HTTP requests from only the authorized IP address via the host-based firewall.

In this case, I’m using nftables to manage the host-based firewall. There’s a sample configuration for nftables on RHEL 10 at /etc/nftables/main.nft. I added the following line to the allow chain:

ip saddr 203.0.113.155 tcp dport 443 accept

The full allow chain now looks like this:

chain allow {
    ct state established,related accept
    meta l4proto @allowed_protocols accept
    iifname @allowed_interfaces accept
    tcp dport @allowed_tcp_dports accept
    ip saddr 203.0.113.155 tcp dport 443 accept
}

To load the ruleset into nftables, I used the following:

$ sudo nft -f /etc/nftables/main.nft

It’s important when working with nftables that you don’t cut off your own access! The sample file at /etc/nftables/main.nft includes SSH as an allowed port in @allowed_tcp_dports, but the configuration is set to reject any connection that is not explicitly allowed. It is also important to note that the sample file also contains other rules you likely won’t need (it allows port 9090/tcp connections from all sources, for example).

Also important to note: changes to nftables are not persistent by default. For example, if you reboot the system and check for existing nftables rules, nothing is returned:

$ sudo nft list ruleset

To persist the rules on RHEL 10, take the following steps:

Uncomment the following line in /etc/sysconfig/nftables.conf:

#include "/etc/nftables/main.nft"

Then, enable and start the nftables service:

$ sudo systemctl enable nftables
$ sudo systemctl start nftables

The nftables service is not a daemon, it just runs at startup (or when the service is started). It is normal for the service to report that it is exited, as in the excerpt below:

$ systemctl status nftables
● nftables.service - Netfilter Tables
     Loaded: loaded (/usr/lib/systemd/system/nftables.service; enabled; preset: disabled)
     Active: active (exited) since Thu 2026-10-08 22:03:58 UTC; 3h 52min ago

You can check and confirm that the rules are present (and that they persist after a reboot):

$ sudo nft list ruleset

What about TLS connections (HTTPS)?

That’s a great question. I did find a site that has what looks to be helpful info, but I have not tested it yet:

How to Configure HAProxy SSL Passthrough for IPv4 Backend Servers

That will be a project for another day.