Simple instructions for reverse proxy

I have a small home network of Raspberry Pi nginx web servers, with a 'primary pi' providing reverse proxy load scheduling to the other machines. In an effort to improve security I have just (successfully) installed certbot on the primary pi.

I am unclear as to any amendments I need to make to the nginx config parameters on the other machines to take advantage of the front end security I have installed or can I just leave them as they were.

Depends, is your internal network secure? Really secure? As in, acceptable for un-encrypted traffic, so you can have the TLS connections terminated at the primary Pi? If that's the case, it should be quite easy to just install the certificate or certificates on your primary Pi. Your primary Pi will then just connect through HTTP to your secondary Pi's, just as it does now.

1 Like

A common pattern is to add two request headers on the "public" load balancer:

  • x-real-ip
  • some rotating "secret" that is shared with the backend server, to identify the request as having come from the loadbalancer. i.e. the gateway sets "x-lan-secret=foo"; and the upstream servers ensure that is in there

In some situations, you may also want/need to add a request header to note the request came in as SSL and was decoded. this way your backend applications know it was secure.

1 Like

Will nginx overwrite those headers by default? Just in case for some reason some client out there sets those headers itself.. Or perhaps to be sure, always clear such used headers first from the incoming request?
I don't think this will happen, but perhaps an ill-configured reverse proxy might go like "Oh gosh, the header is already set, I suppose I shouldn't touch it then, I'll just leave it be!"

1 Like

Thanks for the replies, they clarify my thoughts as to what I could (or should) do.

1 Like

No. No server i know does that. IIRC, the reason is largely because of a lack of standardization in this area and how this is more likely to create problems than fix them. You could have x-forwarded-for or x-real-ip; secrets could appear anywhere else.

I think mod_security and some other firewalls offer an initial locked-down model that can be relaxed.

There are also many ways to set these headers in nginx. there is at least the ngx_http_headers_module, the ngx_http_realip_module , and even the ngx_http_proxy_module.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.