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
