Re: NAT Firewalls and Client IPs in SSL Requests
On 14/01/2012, at 12:29 AM, Stuart Henderson wrote: On 2012-01-12, Sam Vaughan samjvaug...@gmail.com 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@openbsd.org/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
Re: NAT Firewalls and Client IPs in SSL Requests
On 2012-01-12, Sam Vaughan samjvaug...@gmail.com 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@openbsd.org/msg102364.html
NAT Firewalls and Client IPs in SSL Requests
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
