Nginx Reverse Proxy gateway on OpenBSD

Using OpenBSD as a reverse proxy gateway is easy. It’s a solid choice for a perimeter service, and Nginx provides a good number of functions to handle difficult backends. Sometimes applications may already be on SSL / TLS or have complex redirects.

1 /etc/nginx/nginx.conf - base setup
- 1.1 User: www
2 HTTP Reverse Proxy with proxy_pass
3 HTTPs Reverse Proxy with proxy_pass
4 Spring Boot backend on a Kubernetes cluster

/etc/nginx/nginx.conf - base setup

User: www

www is a user on the OpenBSD reverse proxy gateway for the Nginx reverse proxy

Very basic

The key in the following is, that the server_name has a corresponding DNS record on the domain register.

# Take note of http://wiki.nginx.org/Pitfalls

user  www;
worker_processes  8;
...

worker_rlimit_nofile 1024;
events {
    worker_connections  800;
}

http {

    include       mime.types;
    default_type  application/octet-stream;
    client_max_body_size 100M;
    ...

    tcp_nopush     on;
    ...
    gzip  on;
    server_tokens off;

    #
    # server because-security front
    server {
        listen 80 default_server;
        server_name because-security.com www.because-security.com *.because-security.com;

        error_log  "/var/log/nginx/because_security_front_errors.log";

        location / {
            
        ...
            
            root /var/www/html_bs/www11/;
            autoindex off;
        }
        ...
    }

    #
    # server because-security wiki and blog
    server {

        listen 80;
        server_name blog.because-security.com wiki.because-security.com;
        include conf/blog.because_security.com.conf;

    } # end of server - because-security wiki and blog
    
...

These server_name entries redirect the requests to the reverse proxy.

client_max_body_size 100M; can be relevant if you have a Git server you want to reverse proxify

HTTP Reverse Proxy with proxy_pass

If the internal service only uses HTTP without TLS

conf/blog.because_security.com.conf

location / {

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version 1.1;
    proxy_pass http://192.168.1.123:80;

} # end of location

the headers of the requests should contain the original request IPs
the HTTP protocol version will be 1.1 which is important for that particular backend

HTTPs Reverse Proxy with proxy_pass

If the internal service uses HTTP with TLS:

location / {

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Ssl on;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host code.because-security.com;
    client_max_body_size 0;
    
    proxy_http_version  1.1;
    proxy_ssl_verify    off;
    proxy_redirect      off;
    proxy_pass https://192.168.1.124:443;
    

} # end of location

same as above, it should be in a separate file and the header settings should be applied
redirects are disabled
SSL verification off (it’s an IP with a self-signed certificate)
header sets URI to the subdomain

Spring Boot backend on a Kubernetes cluster

This is an excellent use case for such a reverse proxy gateway:

Connection “upgrade” header is set, which is often required for Spring Boot apps with websockets
the proxy_pass points into the Load Balancer on the Kube cluster