Messages

It was a long time ago, just in case you are still looking for an answer, it worked for me. The only difference is that I don't have that "octoprint" in the path to reach my server.

The only "line" from your config I implemented was this.

Code Select Expand

http-request set-header X-Forwarded-Proto https if { ssl_fc }

And I did it in the form of a "rule".



The condition is just a host prefix check.



And now the OctoPrint reverse proxy check passes.

Hi,

After upgrading to 21.7, I don't get an IP address from my ISP after reboot. I have to go to the WAN interface under Interfaces->Overview, and press "renew". I then get an IP address, but after some time (about 30 minutes) the internet stops working (cannot connect from browser). At the same time, I still can see an IP address on the interface on the dashboard.

BTW, the IP address is never shown under Interfaces->Overview, only on the dashboard, or on the console (ifconfig). I remember, before the upgrade, the IP address was shown under Interfaces->Overview, too.

What I see as something potentially wrong, is that the DHCP shows "down" under Interfaces->Overview, and if I log in at the console, the dhclient process is not running.

Shouldn't the dhclient process run in the background all the time? I vaguely remember having seen a check box after the 21.7 upgrade somewhere about running the DHCP client in the background, but I can't find it anymore.

Pressing the "renew" button under Interfaces->Overview fixes the issue (I can browse the internet), but in another 30 minutes I again have to press the "renew" button. If I don't, internet isn't working, although I can see I still have the IP address on the WAN interface.

Thanks,
Miki.

Well, of course a firewall rule was missing (port 443 on the WAN interface), but after all, it looks like there was nothing to do with NAT reflection, I still have all three reflection related options off under Firewall->Settings->Advanced.

There was another thing I didn't think of, though. I mentioned it in an earlier post, that I have an unsecure server, and I secured it by enabling "SSL offloading" in the Public Service settings. However, I still had that strange behavior, that I only could connect to the root of my web server. When I added "nextcloud" to the URL, it was just hanging.

Well, what happened was that nextcloud immediately forwarded me to its index.php/login (not surprisingly), but the HAproxy changed the URL back to HTTP, rather than keeping HTTPS. I could see it in the firewall log, that it was dropping the packets to port 80. As a matter of fact, if I added an "s" to the URL in the browser, it brought up the nextcloud login screen.

Turns out, there was another crucial setting to enable in the public service definition, namely enabling HSTS (HTTP Strict Transport Security). To do that, you have to enable advanced SSL setting in the dialog.

Please, see below my haproxy.conf for your reading pleasure.  ;)

Code Select Expand

#
# Automatically generated configuration.
# Do not edit this file manually.
#

global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin
    nbproc                      1
    nbthread                    1
    tune.ssl.default-dh-param   2048
    spread-checks               2
    tune.chksize                16384
    tune.bufsize                16384
    tune.lua.maxmem             0
    log /var/run/log local0 info

defaults
    log     global
    option redispatch -1
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc

# autogenerated entries for ACLs


# autogenerated entries for config in backends/frontends

# autogenerated entries for stats




# Frontend: gyalogkakukk ()
frontend gyalogkakukk
    http-response set-header Strict-Transport-Security "max-age=15768000"
    bind 0.0.0.0:443 name 0.0.0.0:443 ssl prefer-client-ciphers ssl-min-ver TLSv1.2 ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 crt-list /tmp/haproxy/ssl/60b3a337e588a4.59721209.certlist
    mode http
    option http-keep-alive
    default_backend josie
    # tuning options
    maxconn 100
    timeout client 30s

    # logging options
    option log-separate-errors
    option httplog
    # ACL: www_gyalogkakukk_net
    acl acl_60b3f6269afbe3.91531576 hdr(host) -i www.gyalogkakukk.net

    # ACTION: gyalogkakukk
    use_backend josie if acl_60b3f6269afbe3.91531576

# Backend: josie ()
backend josie
    # health checking is DISABLED
    mode http
    balance roundrobin
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse safe
    server josie 192.168.3.10:80


Gaah! It's not the reverse proxy I am having problem with, but the firewall rules.

I guess I am spoiled by Sophos, which creates all needed firewall rules when you set up a reverse proxy (they call it Web Server Protection), and I did not create any rule. :-/

Also, I thought "NAT reflection" was an automatically working thing, but I can see there are more to it, too. I am now reading the documentation how to configure it.

I didn't see any secrets in haproxy.conf, so I hope I'm not asking too much. Could you post yours, or send it in a private message, please?

Huh! I came to the same conclusion, and just started experimenting with HAproxy.  ;)

Is my understanding correct, that I don't necessarily have to create any condition and rule, I can just have a "real server", "backend pool", and "public service" without any rule? The terms I use may be different in older HAproxy versions, I just upgraded to the latest (os-haproxy-3.3). At least the documentation does not always match what I see in the GUI.

About NAT reflection. I access my nextcloud the same way, always using the public FQDN, even if I'm home, but it is possible to connect to nextcloud locally, just to test if it works at all. I have to mention, my Web server is not secured, so my nextcloud locally is accessed with simple http. I let the firewall add TLS. I believe it would be option #3 at https://docs.opnsense.org/manual/reverse_proxy.html#tls-offloading-downstream-is-tls-protected-upstream-is-plain.

Hi kosta,

It looks like I have the exact same setup, and it doesn't work for me either, but a different way, but later about that.

When you connect to your Nextcloud locally, isn't the URL something like this?

https://192.168.110.6:7443/nextcloud

If you connect to https://nxtcld.domain.com:7443/, you are going to be forwarded to the "root" of your Web server, and perhaps you don't have a default index.html there. I kept the default apache2 ubuntu index.html in my web root, so I get that.

https://www.gyalogkakukk.net

I wonder, if you add "nextcloud" to the URL you are connecting with, would you have the same problem I have, which is that the browser will just hang there, and eventually times out, with "We can't connect to the server at ..." (in Firefox).

P.S. I am in the process of replacing my Sophos UTM 9 with OPNsense, and since this nginx reverse proxy didn't work, I re-connected my old Sophos firewall, so right now my nextcloud works.

Regards,
Miki.