NAT Firewalls and Client IPs in SSL Requests

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

NAT Firewalls and Client IPs in SSL Requests

Sam Vaughan
I have a web server handling predominantly https traffic sitting on a DMZ
behind a CARP'd firewall of two ALIX 2D3s.

Since the firewall is NATting traffic to the web server, the source IP of
requests arriving at the web server is always the firewall's CARP address on
the DMZ.  I'd like the server to see the original client IP.

The only solution I can think of is to use relayd, pound etc. as a layer 7
reverse proxy on the firewall that decrypts the SSL and inserts an
X-Forwarded-For header.  The problem there though is that the firewall is
lightweight with just a 500MHz Geode, whereas the web server has dual quad
core 2.3GHz E5410 Xeons sitting mostly idle.  Even if the firewall can handle
the load now, it'll quickly become a bottleneck if traffic increases.

There might be hardware accelerator products that will work with the ALIX
boards, but it seems to me that scalability in future will depend on
separating the SSL decryption from the firewall.

How can I get the best of both worlds, offloading the SSL decryption from the
firewall without losing the client's IP?  Do any reverse proxies support
handing off just the decryption load to other machines?  How do big sites
separate their SSL decryption from their firewalls without losing this
valuable information?

Thanks in advance,

Sam

Reply | Threaded
Open this post in threaded view
|

Re: NAT Firewalls and Client IPs in SSL Requests

Stuart Henderson
On 2012-01-12, Sam Vaughan <[hidden email]> wrote:
> I have a web server handling predominantly https traffic sitting on a DMZ
> behind a CARP'd firewall of two ALIX 2D3s.
>
> Since the firewall is NATting traffic to the web server, the source IP of
> requests arriving at the web server is always the firewall's CARP address on
> the DMZ.

Do you really have to NAT the source address? That is unusual,
most people just use rdr-to which only touches the destination address.

> I'd like the server to see the original client IP.
>
> The only solution I can think of is to use relayd, pound etc. as a layer 7
> reverse proxy on the firewall that decrypts the SSL and inserts an
> X-Forwarded-For header.

BTW, relayd can also do transparent forwarding (i.e. maintaining the
source address in the packets), even with SSL offload.

http://www.mail-archive.com/misc@.../msg102364.html

Reply | Threaded
Open this post in threaded view
|

Re: NAT Firewalls and Client IPs in SSL Requests

Sam Vaughan
On 14/01/2012, at 12:29 AM, Stuart Henderson wrote:

> On 2012-01-12, Sam Vaughan <[hidden email]> wrote:
>> I have a web server handling predominantly https traffic sitting on a DMZ
>> behind a CARP'd firewall of two ALIX 2D3s.
>>
>> Since the firewall is NATting traffic to the web server, the source IP of
>> requests arriving at the web server is always the firewall's CARP address
on
>> the DMZ.
>
> Do you really have to NAT the source address? That is unusual,
> most people just use rdr-to which only touches the destination address.

Nope, it was a bad set-up!  Somehow I overlooked setting my web server's
default route after installing it.  When debugging the lack of reply traffic
from it I came to the false conclusion that the firewall was dropping replies
to routable IPs on its internal interface and that inbound NAT was needed.

I've now added the default route and restricted NAT to outbound traffic on
the external interface and all is good.

>> I'd like the server to see the original client IP.
>>
>> The only solution I can think of is to use relayd, pound etc. as a layer 7
>> reverse proxy on the firewall that decrypts the SSL and inserts an
>> X-Forwarded-For header.
>
> BTW, relayd can also do transparent forwarding (i.e. maintaining the
> source address in the packets), even with SSL offload.
>
> http://www.mail-archive.com/misc@.../msg102364.html

Looks really handy, thanks for the link, Stuart.  Pulling the IP out of the
X-Forwarded-For header works just fine for my purposes though so I don't
think I need to add the extra complexity of transparent forwarding to my
setup.

I still prefer the idea of doing the SSL offload on internal machines due to
the performance impact on lightweight firewalls.  To keep all the reverse
proxying centralised on the firewalls that probably means a round trip to do
the SSL offload, then a second pass to do the layer 7 filtering and load
balancing to the web servers.

Sam