i'm trying to get HTTPS web interface for transmission. Currently i can access transmission web interface with http://myip:8081 and what i want is to connect with https://myip/transmission . i already setup my lighttpd with TSL/SSL so i can access to default index page at https://myip I enabled mod_proxy lighty-enable-mod proxy Therefore, in /etc/lighttpd/conf-enabled, i have a 10-proxy.conf which is actually a symlink to /etc/lighttpd/conf-available/10-proxy.conf, and this file contains : server.modules += ( "mod_proxy" ) then in lighttpd.conf i added : $SERVER["socket"] == "0.0.0.0:443" { ssl.engine = "enable" ssl.pemfile = "/etc/lighttpd/certs/cert.pem" ssl.cipher-list = "ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM" ssl.honor-cipher-order = "enable" } $HTTP["url"] == "^/transmission/" { proxy.server = ("" => ( ( "host" => "127.0.0.1", "port" => 8081 )) ) } Then I reloaded lighttpd config service lighttpd force-reload Conf Syntax is OK but when i want to access to https://myip/transmission/ I've got a 404 not found page.

I have two raspberry pi servers running. These were set up with DietPi. The one server is used as a NextCloud server. The other (new) server is running weewx. Both use lighttpd as the webserver. Each operates under a different domain my.domain.com and my.otherdomain.com. My router has a single IP address and I use port forwarding to access both servers. The NextCloud server (my.domain.com) has SSL enabled using dietpi-letsencrypt. I cannot run certbot on my.otherdomain.com because I only have one public IP address. I enabled mod-proxy on my Nextcloud machine (my.domain.com) and it forwards requests to my.otherdomain.com to the weewx machine. I disabled port forwarding on the router to the weewx machine. However, dietpi-letsencrypt cannot generate a SSL certificate for the weewx machine - the challenges fail. I tried to run certbot on both machines. Here is the attempt for my Nextcloud machine (used as my proxy server):

Do you want to expand and replace this existing certificate with the new
certificate?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(E)xpand/(C)ancel: E 
Renewing an existing certificate for my.domain.com and my.otherdomain.com
Performing the following challenges:
http-01 challenge for aws.andrewterhorst.com
Using the webroot path /var/www for all unmatched domains.
Waiting for verification...
Challenge failed for domain my.otherdomain.com
http-01 challenge for my.otherdomain.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: my.otherdomain.com
   Type:   unauthorized
   Detail: Invalid response from
   http://my.otherdomain.com/.well-known/acme-challenge/p16SmhyufIGQ75fnhWQ4zxf49TCLfnX4SoWRmBqAHBg 

server.feature-flags       += ("server.h2c"     => "enable")
server.feature-flags       += ("server.graceful-shutdown-timeout" => 5)
#server.feature-flags       += ("server.graceful-restart-bg" => "enable")

# strict parsing and normalization of URL for consistency and security
# https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_http-parseoptsDetails 
# (might need to explicitly set "url-path-2f-decode" = "disable"
#  if a specific application is encoding URLs inside url-path)
server.http-parseopts = (
  "header-strict"           => "enable",# default
  "host-strict"             => "enable",# default
  "host-normalize"          => "enable",# default
  "url-normalize-unreserved"=> "enable",# recommended highly
  "url-normalize-required"  => "enable",# recommended
  "url-ctrls-reject"        => "enable",# recommended
  "url-path-2f-decode"      => "enable",# recommended highly (unless breaks app)
 #"url-path-2f-reject"      => "enable",
  "url-path-dotseg-remove"  => "enable",# recommended highly (unless breaks app)
 #"url-path-dotseg-reject"  => "enable",
 #"url-query-20-plus"       => "enable",# consistency in query string
)

index-file.names            = ( "index.php", "index.html" )
url.access-deny             = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.conf.pl"
include "/etc/lighttpd/conf-enabled/*.conf"

#server.compat-module-load   = "disable"
server.modules += (
	"mod_dirlisting",
	"mod_staticfile",
)


# proxy settings
$HTTP["host"]=~ "my.otherdomain.com"  {
        proxy.balance = "fair"
        proxy.server =  ("" =>
                                (
                                        ( "host" => "192.168.0.261", "port" => 80 ),
                                        ( "host" => "192.168.0.261", "port" => 443 )
                                ))
                        }

Technically, the proxy settings should be in 10-proxy.conf. I need to run this command:

lighty-enable-mod proxy

This creates a symbolic link in /etc/lighttpd/conf-enabled to 10-proxy.conf in /etc/lighttpd/conf-available. I read I could simply add proxy settings in lighttpd.conf - it was not necessary to use 10-proxy.conf. The current set-up means incoming traffic to my.otherdomain.com ends up on the second weewx machine. However, certbot needs to communicate out. I am confused about where I should run certbot - from my weewx machine or from my NextCloud machine? I am not a Linux boffin and need some guidance on how to set up lighttpd to do forward and reverse proxies so my weewx machine can be secure. Most of the posts touching on this refer to Apache, nginx, or some specific web application setup. The syntax of the lighttpd conf settings is rather confusing using regex like notation. For example:

$HTTP['host'] =~ '^(www.example.com)$' {
        url.rewrite-once = ('^/(.*)' => '/vhost/http/%0/$1')
        # In lighttpd we alter the path manually using rewrite rule. %0
        # refers to the hostname and $1 is the path.
        proxy.server = ( '' =>
                ( (
                'host' => '127.0.0.1',
                'port' => 8080
                ) )
        )
}

There is no step by step tutorial in plain simple English for simpletons such as me.

I have a complex nginx setup where a front nginx at ports 80 and 443 handles all outside access including TLS. For files in /texts the frontend-nginx shall proxy request to a second backend-nginx which modifies existing text files on the fly in a complicated process, using up CPU and other resources. For those files *.txt that do not exist (404) I wish not to bother the backend at all but instead provide the client with a default file /texts/default.txt directly. However, currently non-existing files are still only handled in the backend's error_page 404 line. Existing files are served without a problem, the proxy works. This is my config:

frontend-nginx.conf:
http {
    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;
    include /etc/nginx/conf.d/*.conf;

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  frontend.example.org;
        root         /srv/www;

        location /texts/ {

            location ~ \*.txt$ {
                root /srv/www/backend;

                ####### the next line has absolutely no effect
                try_files $uri /texts/default.txt;
            }

            proxy_pass          http://localhost:90;
            proxy_redirect      http://localhost:90/ /;
            proxy_set_header    Host             $host;
            proxy_set_header    X-Real-IP        $remote_addr;
            proxy_set_header    X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_set_header    X-Client-Verify  SUCCESS;
            proxy_set_header    Upgrade          $http_upgrade;
            proxy_set_header    Connection       "upgrade";
            proxy_http_version  1.1;

            proxy_redirect off;
        }
    }
    # https goes here, all the same except TLS
}

backend-nginx.conf:
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;

    server {
        listen       127.0.0.1:90;

        root /srv/www/backend;
        charset utf-8;

        expires -1;  # no-cache
        location ~ /..*\.txt$ {
            # longer cache time for text files
            expires 10m;

            # this actually works but only here in the backend
            error_page  404 @404;
        }

        location @404 {
            return 302 $scheme://frontend.example.org/texts/default.txt
        }
    }
}

` I have that useless statement in the frontend config file which looks to me as if it could handle 404 redirects to default.txt but when I do wget -v http://frontend.example.org/texts/notexist.txt I get a redirect only inside the backend (so proxying does take place).

I'm running jenkins, a java web application, on port 8080 behind an apache2 server using mod_proxy. +---------------+ +----------------+ | apache2 | -----> | jenkins:8080 | +---------------+ +----------------+ When I access jenkins directly e.g. http://myhost:8080/ the result looks normal (All characters are encoded correct). But when I try it through the apache proxy it looks like this My mod_proxy configuration is SSLEngine on ProxyRequests Off ProxyPreserveHost On AllowEncodedSlashes NoDecode Order deny,allow Allow from all ProxyPass / http://localhost:8080/ nocanon ProxyPassReverse / http://localhost:8080/ RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443" SetOutputFilter proxy-html SetOutputFilter INFLATE;proxy-html;DEFLATE SetEnv proxy-nokeepalive 1 Header edit Location ^http://myhost/ https://myhost/ My language settings are # echo $LANG en_US.utf8 # echo $LC_ALL en_US.utf8 Does anyone know how to keep the correct charset?

I'm trying to replace Apache with OpenBSDs httpd but can't figure out what to do with my ProxyPass statements. In apaches conf it looks like this ProxyPass /someurl http://192.168.123.123/someotherurl ProxyPassReverse /someurl http://192.168.123.123/someotherurl - I thought I should use relayd for this, but how do I do the URL rewrite? - Would I set up relayd to listen on port 80 and forward some things to different internal machines and the rest to httpd on localhost?

I have a gitlab server next to my web server running on my home network. On my web server I run Apache2 with some domains. One of them is example.com. Now my aim is that the user receives the gitlab login page when visiting something like example.com/gitlab or gitlab.example.com. Actually I do not care whether the redirection happens from a certain url or a subdomain. I've already tried quite much but nothing of this worked for me (probably I did it wrong all times). I also read some related forum posts like - https://unix.stackexchange.com/questions/349218/use-apache-virtual-host-to-redirect-a-subdomain-to-internal-ip-preserving-passed - https://unix.stackexchange.com/questions/209300/use-apaches-name-based-virtual-host-to-redirect-to-internal-ip - https://www.linuxquestions.org/questions/linux-server-73/apache-redirect-to-internal-server-919321/ - ... But I didn't get anything up and running. My *default.conf* is configured that it always redirects Port 80 to Port 443 (HTTPS). ServerName example.com ServerAlias www.example.com Redirect permanent / https://www.example.com/ [...] So here is my *example.com.conf* before: ServerName example.com ServerAlias www.example.com DocumentRoot /var/www/html/example.com SSLEngine on SSLOptions +StdEnvVars SSLOptions +StdEnvVars Include /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile /etc/letsencrypt/live/www.example.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/www.example.com/privkey.pem First I tried to redirect **from a certain url**. I added: ProxyRequests Off ProxyPass /gitlab http://192.168.0.115:80/ ProxyPassReverse /gitlab http://192.168.0.115:80/ This does not work completly but if I enter the url, I get *"404 The requested URL /users/sign_in was not found on this server"*. '/users/sign_in' is the path of the login page of my gitlab so server, so at least something seems to work. Strange to me is that it works if I redirect the root directory to my internal IP: ProxyRequests Off ProxyPass / http://192.168.0.113:80/ ProxyPassReverse / http://192.168.0.113:80/ This works but now I can't access my actual website anymore. Then I tried redirection **from a subdomain**. I added: ServerName gitlab.example.com ProxyPass / http://192.168.0.113/ ProxyPassReverse / http://192.168.0.113/ But I receive *"The website is unreachable"*. I don't even get the subdomain running.

I've got one Raspberry Pi 2 Model B running Deluge and Deluge Web UI 24/7. I set up a No-IP free host so I can access the Rasperry Pi to download some data I've stored in a 3TB disk. I am using Apache2 as the webserver but I am looking forward to change to a Go application I am creating myself. The WebUI Deluge listening port is **9090**. I wanted to access Deluge WebUI without having to type :9090 in the end of the hostname (via /del would be ideal). I read multiple questions on SO where the Reverse Proxies were mentioned. I quickly checked the official documentation. The changes I've made to my configuration files are the following: */etc/apache2/sites-enabled/000-default.conf* ProxyPass /del http://hostname:9090/ ProxyPassReverse /del http://hostname:9090/ I also tried **rewrite** in 000-default (but in different times) RewriteEngine on RewriteCond %{REQUEST_URI} /del [NC] RewriteRule ^(.*)$ http://hostname:9090 [P] Restarted Apache and the result is a blank page whenever I visit http://hostname/del **(via browser)**

Say I have a public-facing Nginx reverse proxy container (A) that sends traffic to a downstream web service (B). This A container is where TLS connections terminate. The Docker server is _also_ behind an external reverse proxy service. I am **successfully** able to extract and log the real IPs from forward headers. No problem. How to configure the fail2ban action to jail (e.g. DROP) traffic from the real IP exiting container A? The downstream web service B will see an XFF header with the real IP. Here is what my iptables are doing now (iptables -nL): Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-auth-fail tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 Chain FORWARD (policy ACCEPT) target prot opt source destination DOCKER-USER all -- 0.0.0.0/0 0.0.0.0/0 DOCKER-ISOLATION-STAGE-1 all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED DOCKER all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED DOCKER all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain DOCKER (2 references) target prot opt source destination ACCEPT tcp -- 0.0.0.0/0 172.20.128.1 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 172.20.128.1 tcp dpt:80 Chain DOCKER-ISOLATION-STAGE-1 (1 references) target prot opt source destination DOCKER-ISOLATION-STAGE-2 all -- 0.0.0.0/0 0.0.0.0/0 DOCKER-ISOLATION-STAGE-2 all -- 0.0.0.0/0 0.0.0.0/0 RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain DOCKER-ISOLATION-STAGE-2 (2 references) target prot opt source destination DROP all -- 0.0.0.0/0 0.0.0.0/0 DROP all -- 0.0.0.0/0 0.0.0.0/0 RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain DOCKER-USER (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-auth-fail (1 references) target prot opt source destination DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 STRING match "X-Forwarded-For: 184.75.215.178" ALGO name bm TO 65535 RETURN all -- 0.0.0.0/0 0.0.0.0/0 As you can see I'm already trying to match on packets with the XFF string, and that IP address is the real IP, not the proxy server. Perhaps the INPUT chain is the culprit? Here are my main actions: actionstart = iptables -N fail2ban- iptables -A fail2ban- -j RETURN iptables -I -p --dport -j fail2ban- actionban = iptables -I fail2ban- 1 -p tcp --dport 80 -m string --algo bm --string 'X-Forwarded-For: ' -j DROP

When inspecting the system logs of some other issue, I noticed that I was getting lots of SSH attempts in real time. Specifically I have about 10'000 attempts daily !

$ grep Disconnected /var/log/auth.log | wc -l #since March 6
46149

This was quite an eye-opener to me, as I am behind a NAT and normally have 0 logon attempts. From the logs I got a clear hint as to what was going on: the logon attempts were all from localhost!

Mar 10 11:27:38 devbox sshd: Disconnected from invalid user mn 127.0.0.1 port 45822 [preauth]
Mar 10 11:27:46 devbox sshd: Disconnected from authenticating user root 127.0.0.1 port 45824 [preauth]

The only thing I could come up with that made sense, was that these connections originated from the reverse SSH tunnel I have established towards my jump host to be able to login to my work computer from home. And indeed, when doing sudo systemctl stop reverse-tunnel all activity stopped immediately! So something about my setup is fishy. Up until now, I had assumed that my setup required the client side to be able to login to the jump host using a certificate valid for that host to be allowed to initiate a connection, but this was clearly wrong! # Setup ## The client side .ssh/config

Host jump
    HostName jumphost.somedomain.com
    User ubuntu
    IdentityFile ~/.ssh/jump

# local -> jump -> jump:30001 --> work
# reverse tunnel: work -> jump:22 sets up jump:30001 -> work
Host work
    ProxyJump jump
    User my-user
    IdentityFile ~/.ssh/work
    HostName jumphost.somedomain.com
    Port 30001

The above seems fine, as that just covers the "client side" bit, telling my local computer how to connect. ## The reverse tunnel service This is setup as a systemd service that always is running and is what actually allows inbound connections from the jump host to my work computer. This is the prime suspect.

# The SSH tunnel is configured mostly through options specified in the default ssh config file (such as private key)
# It needs to be copied to /etc/systemd/system/ to be picked up and then run
#    sudo systemctl daemon-reload
#    sudo systemctl enable tunnel
#    sudo systemctl start tunnel
# Original implementation: https://askubuntu.com/a/1316825/165026 

[Unit]
Description=Maintain Reverse SSH Tunnel
After=network.target

[Service]
User=my-user
ExecStart=/usr/bin/autossh  -o ServerAliveInterval=30 -o "ServerAliveCountMax 3" -M 44444 -o ExitOnForwardFailure=yes -gnNT -R 30001:localhost:22 jump
RestartSec=15
Restart=always
KillMode=mixed

[Install]
WantedBy=multi-user.target

I suspect this bit to be the culprit: -R 30001:localhost:22 jump

after 5 hours of spending time to configure Jitsi on my Plesk server inside Docker, I need to give up and ask you — sorry for that. First, I've followed the tutorial here: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker I've created a custom subdomain on my server meet.my-domain.de and downloaded the latest release: https://github.com/jitsi/docker-jitsi-meet/archive/refs/tags/stable-9955.zip I've unziped it and created a .env from the template. I've executed the script to set a password and changed the following values:

HTTP_PORT=8000
HTTPS_PORT=8448
PUBLIC_URL=https://meet.my-domain.de:${HTTPS_PORT} 
DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
ENABLE_LETSENCRYPT=0

Since I handle SSL inside Plesk by a reverse proxy, I've followed this tutorial to disable HTTPS inside the .env: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker/#running-behind-a-reverse-proxy Also, I needed to change the composer file because the port 8080 is reserved by ruby in my system:

# Video bridge
    jvb:
        image: jitsi/jvb:${JITSI_IMAGE_VERSION:-stable-9955}
        restart: ${RESTART_POLICY:-unless-stopped}
        ports:
            - '${JVB_PORT:-10000}:${JVB_PORT:-10000}/udp'
            - '127.0.0.1:${JVB_COLIBRI_PORT:-8085}:8080' :  Strophe: Websocket error {"isTrusted":true} Websocket error {"isTrusted":true}

Any idea what I am missing here?

I'm trying to configure Focalboard to run in a specific subdirectory using Nginx. I followed the steps from the official Focalboard documentation and was able to set it up normally. However, after moving Focalboard to the /focalboard subdirectory, the WebSocket connection started showing issues. Nginx Configuration:

upstream focalboard {
   server localhost:8000;
   keepalive 32;
}

server {
   listen 443 ssl;
   server_name example.com;

   ssl_certificate /path/to/certificate.crt;
   ssl_certificate_key /path/to/certificate.key;
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   ssl_ciphers HIGH:!aNULL:!MD5;

   # WebSocket configuration
   location /focalboard/ws/ {
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       client_max_body_size 50M;
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_buffers 256 16k;
       proxy_buffer_size 16k;
       client_body_timeout 60;
       send_timeout 300;
       lingering_timeout 5;
       proxy_connect_timeout 1d;
       proxy_send_timeout 1d;
       proxy_read_timeout 1d;
       proxy_pass http://focalboard ;
   }

   # Default configuration for Focalboard
   location /focalboard/ {
       client_max_body_size 50M;
       proxy_set_header Connection "";
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_buffers 256 16k;
       proxy_buffer_size 16k;
       proxy_read_timeout 600s;
       proxy_cache_revalidate on;
       proxy_cache_min_uses 2;
       proxy_cache_use_stale timeout;
       proxy_cache_lock on;
       proxy_http_version 1.1;
       proxy_pass http://focalboard/ ;
   }
}

Focalboard config.json:

{
    "serverRoot": "https://example.com/focalboard ",
    "port": 8000,
    "dbtype": "sqlite3",
    "dbconfig": "./focalboard.db",
    "postgres_dbconfig": "dbname=exampledb sslmode=disable",
    "useSSL": false,
    "webpath": "./pack",
    "filespath": "./files",
    "telemetry": true,
    "prometheusaddress": ":9092",
    "session_expire_time": 2592000,
    "session_refresh_time": 18000,
    "localOnly": false,
    "enableLocalMode": true,
    "localModeSocketLocation": "/var/tmp/example_local.socket"
}

After applying this configuration, I'm repeatedly getting the following error:

close, re-opening websocket

The WebSocket connection keeps closing unexpectedly and immediately reopening, which creates a constant loop. - Is there something wrong or missing in my Nginx WebSocket configuration? - How can I fix the WebSocket disconnection issue when running Focalboard in a subdirectory?

I have this custom.conf for a Apache Docker container

ServerName https://staging.smartreparatur.at 

# Enable Gzip compression (Deflate)

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
DeflateCompressionLevel 9



DirectoryIndex index.php
Options FollowSymLinks
AllowOverride All
Require all granted


# Enable caching for static assets

ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"



# Security headers

Header set X-Content-Type-Options "nosniff"
#        Header set X-Frame-Options "SAMEORIGIN"
Header set X-XSS-Protection "1; mode=block"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"



# Enable logging
# Log to standard output (stdout)
CustomLog /proc/self/fd/1 common
ErrorLog /proc/self/fd/2

it's for an Apache Docker container behind a reverse proxy. The website only works, if I set the ServerName with the https:// protocol although it is not needed / allowed according to the Apache documentation. When removed, trying to open the website results in a redirect loop. Here is my full question with more details, can't be posted here directly GIST full question for StackExchange based on this suggestion Suggestion to add link to a Gist

I have an ASP.NET app hosted in a Docker container, with a NGINX reverse proxy, hosted on a VPS. When running in production, the x-forwarded-proto header isn't being passed. From what I understand, this should return the x-forwarded-proto header curl -I https://awaken.hanumaninstitute.com The result is

HTTP/1.1 200 OK
Server: nginx/1.22.1
Date: Sun, 01 Sep 2024 02:35:33 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding

The NGINX server block is this

server {
server_name   awaken.hanumaninstitute.com;

location /.well-known/acme-challenge/ {
root /var/www/certbot;
}

location / {
proxy_pass         http://127.0.0.1:5009/ ;
proxy_http_version 1.1;
proxy_set_header   Upgrade $http_upgrade;
proxy_set_header   Connection $connection_upgrade;
proxy_set_header   Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header   X-Forwarded-Proto $scheme;
}

listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/awaken.hanumaninstitute.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/awaken.hanumaninstitute.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

The ASP.NET app has this

var app = builder.Build();
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

Server is Debian. What am I missing? Why isn't x-forwarded-proto working?

I recently wanted to switch all my internal servers over to TLSv1.3 from TLSv1.2 as they are all kept very up to date and do not need to support older devices. My setup is: A reverse proxy, at 192.168.20.2 (Debian 11, NGINX v1.21.6). This terminates the public valid lets encrypt certificates and will continue to use TLSv1.2 and TLSv1.3 to support a variety of clients. The requests are forwarded via the server_name to the correct backend server IP via another TLS session. Several backend servers, but for simplicity we will just talk about one (all the configs are identical). Backend server, at 192.168.30.2 (Debian 11, NGINX v1.21.6). This terminates another TLS session (started by the reverse proxy, using a self-signed internal certificate) at which point the web server index files are served. My goal has been to decommission TLSv1.2 on all the backend servers, since that TLS session has both client and server controlled by me, so maintaining compatibility with new TLS versions is do-able. I went in to the ssl-params.conf that I point out in the main site configuration and simply removed TLSv1.2 from the ssl_protocols part. Upon restart of NGINX (it did restart fine, no errors), I attempt to browse to the site and get a 502 Bad Gateway. I thought perhaps the problem was removing TLS1.2, but upon running a curl from the Reverse Proxy itself, I was able to get the web server index file served no problem. Therefore, I assume, the issue lies in the Reverse Proxy NGINX server. There is probably some obscure TLS NGINX gotcha' that I am missing here. I can't seem to find anything online, so hopefully someone can point out my issue? If you are wondering why I use TLS to a backend server, it is because the connection between the reverse proxy and the backend server ride over an untrusted portion of the network, therefore I encrypt. Here are all the relevant configs for the connect to a particular backend site. ### Reverse Proxy:

# configuration file /etc/nginx/nginx.conf:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}
http {
        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        server_tokens off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # Rate Limiting
        ##

        limit_conn_zone $binary_remote_addr zone=limit_conn:1m;
        limit_conn limit_conn 100;
        limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=5r/s;

        ##
        # Gzip Settings
        ##

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        client_max_body_size 10000m;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/sites-enabled/*;

        ##
        # Hardening
        ##
 
        add_header Allow "GET, POST, HEAD" always;
}


# configuration file /etc/nginx/snippets/ssl-params.conf:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
resolver 192.168.20.1 valid=300s;
resolver_timeout 5s;

ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

# configuration file /etc/nginx/sites-enabled/wiki.domain.com:
server {
        listen 443 ssl http2;
        ssl_certificate /etc/letsencrypt/live/wiki.domain.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/wiki.domain.com/privkey.pem;
        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_trusted_certificate /etc/letsencrypt/live/wiki.domain.com/chain.pem;
        include snippets/ssl-params.conf;
        server_name wiki.domain.com;
        location / {
                proxy_pass https://192.168.30.2 ;
                proxy_set_header X-Real-IP $remote_addr;
        }
}

### Backend server:

# configuration file /etc/nginx/nginx.conf:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # Logging Settings
        ##

        access_log off;
        error_log  off;

        ##
        # Gzip Settings
        ##

        gzip on;

        client_body_buffer_size 1K;
        client_header_buffer_size 1k;
        client_max_body_size 10k;
        large_client_header_buffers 2 1k;

        server_tokens off;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/sites-enabled/*;
}

# configuration file /etc/nginx/sites-enabled/dokuwiki.conf:
server {
    listen 443 ssl http2;
    include snippets/self-signed.conf;
    include snippets/ssl-params.conf;

    server_name _; 

    root         /var/www;
    index        index.html;
}

# configuration file /etc/nginx/snippets/self-signed.conf:
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

# configuration file /etc/nginx/snippets/ssl-params.conf:
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 192.168.30.1 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header Content-Security-Policy "default-src 'self';";
add_header X-XSS-Protection "1; mode=block";

ssl_dhparam /etc/ssl/certs/dhparam.pem;

*I just used a default index.html for the backend server for testing.* When I attempt to browse **from a client machine to the reverse proxy**:

user@clientmachine:~$ curl -vvvv https://wiki.domain.com 
*   Trying PUBLICIP:443...
* Connected to wiki.domain.com (PUBLICIP) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=wiki.domain.com
*  start date: May 17 09:56:32 2022 GMT
*  expire date: Aug 15 09:56:31 2022 GMT
*  subjectAltName: host "wiki.domain.com" matched cert's "wiki.domain.com"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55619a9a25c0)
> GET / HTTP/2
> Host: wiki.domain.com
> user-agent: curl/7.74.0
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!

502 Bad Gateway

502 Bad Gateway
nginx


* Connection #0 to host wiki.domain.com left intact

When I attempt to browse to the backend server **from the Reverse Proxy to the backend**:

user@revproxy:~$ curl -kvvvv https://192.168.30.2/ 
*   Trying 192.168.30.2:443...
* Connected to 192.168.30.2 (192.168.30.2) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=State; L=city; O=; CN=192.168.30.2
*  start date: Dec 10 16:29:30 2021 GMT
*  expire date: Feb 26 16:29:30 2031 GMT
*  issuer: C=US; ST=State; L=city; O=; CN=192.168.30.2
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x555ab8d305c0)
> GET / HTTP/2
> Host: 192.168.30.2
> user-agent: curl/7.74.0
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!




  
  Spoon-Knife
  






  Fork me? Fork you!


  I made a change




* Connection #0 to host 192.168.30.2 left intact

Of course, if I add the TLSv1.2 back into ssl-params.conf in the ssl_protocols section on the backend server, then the client request suddenly goes through (client still using TLSv1.3 for the initial connection to the Reverse Proxy)

I have configured a reverse proxy in Apache2. It gets requests by HTTPS - unwraps the HTTPS and then forwards to local HTTP-processes for /web and /rest. ProxyPass /web http://127.0.0.1:8080/web ProxyPassReverse /web http://127.0.0.1:8080/web ProxyPass /rest http://127.0.0.1:8181 ProxyPassReverse /rest http://127.0.0.1:8181 ServerName myserver123.abc.xyz.org ProxyPreserveHost On SSLEngine On SSLProxyEngine On SSLCertificateFile /etc/apache2/certs/server.cer SSLCertificateKeyFile /etc/apache2/certs/server.key This is working fine. Every request to / is forbidden. But now I try to forward every request to / to /web instead of the 403-forbidden response. I inserted this before the ServerName line. ProxyPass / http://127.0.0.1:8080/web ProxyPassReverse / http://127.0.0.1:8080/web But does not work. All I get in the browser is > **Bad Request** Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled > server port. Instead use the HTTPS scheme to access this URL, please. How can I get me forward from / to /web?

Is it possible to configure httpd to redirect HTTPS traffic from one host:port to another without decrypting it? I've got HTTPS traffic coming in at port 443. Depending on the incoming SNI I'd like httpd to redirect the request to a different host:port. Normally, I'd use a reverse proxy, but I've got one additional constraint: I cannot provide httpd with the SSL key. Is it possible for it to redirect traffic without decrypting it first? httpd won't be able to access the host header because it's not allowed to decrypt the request. Here's what I've got so far:

ServerName example.com

    SSLProxyEngine On
    ProxyRequests Off
    ProxyPreserveHost On
    ProxyStatus On

    
        Require all granted
    

    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
    RequestHeader set "X-Forwarded-SSL" expr=%{HTTPS}
    
    ProxyPass / https://localhost:8443/ retry=0
    ProxyPassReverse / http://localhost:8443/

When I hit example.com on port 443, it looks like httpd is trying to process it as HTTP (plain text) traffic, and no redirection takes place.

I'm doing this all on Debian 12 VPS. * I can install [easypanel](https://easypanel.io) separately & get it working with SSL enabled. * I can install [btcpayserver](https://github.com/btcpayserver/btcpayserver-docker/) separately using [this guide](https://sethforprivacy.com/guides/accepting-monero-via-btcpay-server/) to get BTC/XMR working. * But I can't manage to get both of them working on the same VPS at the same time. I'v tried installing Easypanel first & then installing BTCPayServer but BTCPayServer doesn't get installed at all giving me an error that says:

ERROR: for nginx: Bind for 0.0.0.0:443 failed: port is already allocated

Now I've went the opposite way & installed BTCPayServer first & later on installed EasyPanel. Now it is working. But I can't access my Next.js app that is running on easypanel. I can't even setup a custom URL that on easypanel.mysite.com for some reason. I'm thinking this is due to Nginx which BTCPayServer uses or Traefik which EasyPanel uses. I currently get 503 Service Temporarily Unavailable when I try to open the Next.js app I installed on EasyPanel. How do I go about solving this problem? Easypanel has a [doc about this](https://easypanel.io/docs/guides/custom-traefik-config) . So I did what it said with the help of [Perplexity](https://perplexity.ai) : ### /etc/easypanel/traefik/config/custom.yaml

# Enable debug logs
log:
  level: DEBUG

# Define the entry points
entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"

# Enable and configure Let's Encrypt
certificatesResolvers:
  myresolver:
    acme:
      email: "myemail@gmail.com"
      storage: "/etc/traefik/acme/acme.json"
      httpChallenge:
        entryPoint: "web"

# Configure the API
api:
  insecure: true
  dashboard: true

# Define the global configuration
global:
  checkNewVersion: true
  sendAnonymousUsage: true

# Configure access to Docker
providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false

# Configure the entry points for the services
http:
  routers:
    btcpayserver-router:
      rule: "Host(btcpay.mysite.com)"
      service: "btcpayserver-service"
      entryPoints:
        - "websecure"
    easypanel-router:
      rule: "Host(easypanel.mysite.com)"
      service: "easypanel-service"
      entryPoints:
        - "websecure"

  services:
    btcpayserver-service:
      loadBalancer:
        servers:
          - url: "http://btcpayserver-docker:80 "
    easypanel-service:
      loadBalancer:
        servers:
          - url: "http://easypanel:80 "

But I can't find out what http://btcpayserver-docker:80 should be replaced with. When I ran docker ps --format "table {{.ID}}\t{{.Names}}" I got this:

CONTAINER ID   NAMES
969e4c50ec21   easypanel.1.vzayltvbta10oaqc3wpnztkq2
37e61e15eab5   sinister-kings_nextjs-app.1.lym2ck5oa18gdtfr3lcirz9rf
7999d7177605   letsencrypt-nginx-proxy-companion
24691446a0bd   nginx-gen
d295cc6dbcd3   btcpayserver_monero_wallet
9f2ed203c36d   generated_nbxplorer_1
b9b8b4463c3d   btcpayserver_bitcoind
f6337df09401   generated_btcpayserver_1
696ff12c318d   tor-gen
aa89e0b619b2   generated_postgres_1
fe8d006707dd   nginx
11cf23a5363d   btcpayserver_monerod
f7d42ade4300   tor

Which one of the btcpayserver do I use on the custom traefik config? Is that config all I need? I know I have to use Reverse Proxy & make one of them go through the others ports but I'm confused on how do I make that work?

I use Nginx on Ubuntu 16.04 for using Guacamole as RDP clientless. This is working perfectly on my computer which is in an external LAN. But not working in another external LAN which have proxy (work area). When I go to the app from my browser : http://myserverguaca/guacamole/ I can see log-in page and I can log on. But when I try to start the RDP there is a loading, then a message that says: The server take to many to time to be respond. Do you think I have to forward another port ? I have forwarded the port 8080 to 80, RDP use : 3389, but this is in localhost, don't know why I should forward this too and how I can do it. There is the configuration of my RDP access (user-mapping.xml) rdp localhost 3389 fr-fr-azerty true and my config on nginx (sites-enabled/guacamole) server { listen 80; server_name vpsmyserver.net.com; location /guacamole/ { proxy_pass http://localhost:8080/guacamole/; proxy_buffering off; proxy_http_version 1.1; proxy_set_header X_Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; access_log off; } }

I'm having a hard time on this... My server sets multiple cookies and wants to rewrite one of them by appending ";SameSite=None" to it. Prefer not to append this to all Set-Cookie headers. I want to rewrite this set cookie header

-Cookie: my-cookie=xyz; Path=/; ...;Secure; HttpOnly

to

-Cookie: my-cookie=xyz; Path=/; ...;Secure; HttpOnly; SameSite=None

. I'm using nginx 1.21.4. Trying several with

but with no success. W

i have a raspberry pi with multiple services running (e.g. Openhab, mosquitto, ...). each service should be locally reachable via a local subdomain (openhab.core.local, mosquitto.core.local, ...) Of course, there seems to be a simple solution - mDNS. But here comes the problem: Here we the the mDNS discovery. The service, port and local IP are recognised correctly. Everything goes on the right network client to port 80 where an nginx (also tried Traefik) reverse proxy container awaits for requests to route. But I cannot reach the services. I've figured out that the DNS Rebind protection in the FritzBox will not answer DNS questions which resolves to the internal network, ok. Ive configured the exceptions for the desired domain names. (also tried with several subdomains different configs) Where I do not quite understand why it needs an DNS server response if we already have the mDNS entry, but ok. Nothing changed. So the client knows that home.pink-core.local should go to 10.0.0.40:80 where the nginx waits. The services are up and running. But the client seems to makes an DNS request with no resolution despite of whitelisting in fritzbox. At least the services are not reachable. How to figure out the reason and resolve this?