Messages

Hi,

I tried to enable http3/quic for my HTTP servers by checking the corresponding box in the nginx configuration.
This allowed me to determine that the following entries were added to nginx.conf:

Code Select Expand

listen 443 quic reuseport;
listen [::]:443 quic reuseport;
add_header Alt-Svc 'h3=":443"; ma=86400' always;
If http3/quic is then activated for another HTTP server, all these entries are also set for that server.
However, this then leads to the following error message:

Code Select Expand

nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
nginx: [emerg] duplicate listen options for 0.0.0.0:443 in /usr/local/etc/nginx/nginx.conf

Apparently, the reuseport option can only be used once:
https://stackoverflow.com/questions/76348128/enabling-quic-http-3-on-multiple-domains-with-nginx-1-25


How can http3/quic be enabled for additional HTTP servers without causing the error?

There was obviously something wrong with the configuration.

Unfortunately, even after intensive searching and reconfiguring, I couldn't find out exactly where the error was.


I have now reset OPNsense to version 24.7.10 and restored a configuration from 3 days ago.

nginx could then be started again. I then carried out the update to version 24.7.11_2 again.


Now everything works again.

Hi,


I have recently upgraded from OPNsense 24.7.10 to the current version 24.7.11_2.
No other changes were made to the nginx configuration.

Since a restart, the nginx service can no longer be started.

log says:

Code Select Expand

2024-12-20T10:44:37 Emergency nginx nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
2024-12-20T10:44:37 Emergency nginx nginx: [emerg] no "ssl_certificate" is defined for the "listen ... ssl" directive in /usr/local/etc/nginx/nginx.conf:8175
2024-12-20T10:44:36 Debug nginx NGINX setup routine started.
The nginx.conf looks like this from the mentioned line 8175 onwards_

Code Select Expand

server {

    listen 80 default_server;
    listen [::]:80 default_server;


    sendfile On;
    server_name  example.com;

    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
    charset utf-8;
    access_log  /var/log/nginx/example.com.access.log main;
    access_log  /var/log/nginx/tls_handshake.log handshake;
    error_log  /var/log/nginx/example.com.error.log error;
    #include tls.conf;
    error_page 403 /opnsense_error_403.html;
    error_page 404 /opnsense_error_404.html;
    error_page 405 /waf_denied.html;
    error_page 500 501 502 503 504 /opnsense_server_error.html;

    location = /opnsense_error_403.html {
        internal;
        root /usr/local/etc/nginx/views;
    }
    location = /opnsense_error_404.html {
        internal;
        root /usr/local/etc/nginx/views;
    }
    location = /opnsense_server_error.html {
        internal;
        root /usr/local/etc/nginx/views;
    }
    # location to ban the host permanently
    set $naxsi_extensive_log 0;
    location @permanentban {
        access_log /var/log/nginx/permanentban.access.log main;
        internal;
        add_header "Content-Type" "text/plain; charset=UTF-8" always;
        return 403 "You got banned permanently from this server.";
    }
    error_page 418 = @permanentban;
    location = /waf_denied.html {
        root /usr/local/etc/nginx/views;
        access_log /var/log/nginx/waf_denied.access.log main;
    }
    location ^~ /.well-known/acme-challenge/ {
        default_type "text/plain";
        proxy_pass http://127.0.0.1:43580;
    }
    # block based on User Agents defined in global http settings
    if ($http_user_agent ~* Python-urllib|Nmap|python-requests|libwww-perl|MJ12bot|Jorgee|fasthttp|libwww|Telesphoreo|A6-Indexer|ltx71|okhttp|ZmEu|sqlmap|LMAO/2.0|l9explore|l9tcpid|Masscan|zgrab|Ronin/2.0|Hakai/2.0|Indy\sLibrary|^Mozilla/[\d\.]+$|Morfeus\sFucking\sScanner|MSIE\s[0-6]\.\d+) {
        return 418;
    }
    location /opnsense-auth-request {
      internal;
      fastcgi_pass  unix:/var/run/php-webgui.socket;
      fastcgi_index index.php;
      fastcgi_param TLS-Cipher $ssl_cipher;
      fastcgi_param TLS-Protocol $ssl_protocol;
      fastcgi_param TLS-SNI-Host $ssl_server_name;
      fastcgi_param Original-URI $request_uri;
      fastcgi_param Original-HOST $host;
      fastcgi_param SERVER-UUID "337026df-317a-49d2-9526-172c5b38bcc4";
      fastcgi_param SCRIPT_FILENAME  /usr/local/opnsense/scripts/nginx/ngx_auth.php;
      fastcgi_param AUTH_SERVER "Local Database";
      fastcgi_intercept_errors on;
      include        fastcgi_params;
    }
    include 337026df-317a-49d2-9526-172c5b38bcc4_pre/*.conf;


location  / {
    BasicRule wl:19;
    DeniedUrl "/waf_denied.html";
    if ($scheme != "https") {
        return 302 https://$host$request_uri;
    }
    autoindex off;
    proxy_set_header Host $host;
    proxy_set_header X-TLS-Cipher $ssl_cipher;
    proxy_set_header X-TLS-Protocol $ssl_protocol;
    proxy_set_header X-TLS-SNI-Host $ssl_server_name;
    # proxy headers for backend server
    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-Forwarded-Port $server_port;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-TLS-Client-Intercepted $tls_intercepted;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
    proxy_ignore_client_abort off;
    proxy_request_buffering off;
    proxy_max_temp_file_size 1024m;
    proxy_buffering off;
    proxy_pass https://upstreamb7b7de2accac4d758e74637ac2fd5380;
    proxy_ssl_server_name off;
    proxy_ssl_protocols TLSv1.2 TLSv1.3;
    proxy_ssl_session_reuse off;
    proxy_ssl_trusted_certificate /usr/local/etc/nginx/key/trust_upstream_b7b7de2a-ccac-4d75-8e74-637ac2fd5380.pem;
    proxy_ssl_verify off;
    proxy_ssl_verify_depth 1;
    proxy_store off;
    proxy_hide_header X-Powered-By;
    include 0b649b16-f937-41e3-8518-27b394057e1a_post/*.conf;
}
    include 337026df-317a-49d2-9526-172c5b38bcc4_post/*.conf;

Where is the mistake here?

Thank you for your assessment.
I see from this that it should obviously not be done with a small adjustment to the configuration.
That actually sounds very advanced to me.

What should be done to warm up the servers after the nginx start?

I had originally activated the function to have maximum security.
So would you recommend deactivating ocsp must staple instead?

OK. I wasn't aware of that.

What would be needed for a functioning solution?

Ok, thanks for the feedback.

With the "regular" configuration and a few adjustments, Nextcloud is running and I have not been able to detect any errors so far.
I was also able to get an A+ ranking in the Nextcloud security scan and at securityheaders.com.

I just wanted to make sure that the web server is optimally configured.

I haven't got anything yet.
However, I have found these instructions here:
https://www.kuketz-blog.de/nginx-aktivierung-von-ocsp-must-staple-ohne-timeout/

But I don't know how this could be implemented in OPNsense.

suggested config is for NC on the same host with nginx (/var/www/nextcloud)

Hi,
Unfortunately, this is not practicable with the Docker installation of Nextcloud.

Hello,

I encountered this problem with my setup (OPNsense 23.7.10).

here it is described that for troubleshooting ssl_stapling_file can be used.

How can I use ssl_stapling_file?

Hello,

the official Nextcloud documentation provides extensive recommendations for the correct configuration of the upstream nginx.

Unfortunately, I find it difficult to transfer the configuration from the example to the nginx configuration of the OPNsense, as the configuration there has a completely different structure.

Can someone here help me to create the optimal configuration under OPNsense according to the Nextcloud documentation?

Does anyone have any ideas about this?

I get this error message virtually every time I first open a page in Firefox:
MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING

In some cases, it then does not continue beyond this error message on subsequent page loads.

But I would not like to miss the OSCP-Stapling feature.

Hello,


I encountered this problem with my setup (OPNsense 23.7.2-amd64).


here it is described that for troubleshooting ssl_stapling_file can be used.


How can I use ssl_stapling_file?

Had the same problem after upgrading to 23.1.

In the console it said

Code Select Expand

Starting web GUI...failed.
Trying to access the webgui gave me error "503 - Service unavailable".
I've also nginx on Port 80 and 443 running, and the webgui listens to 8443.
It seems that this port was already in use.

After a restart of OPNsense I can access the webgui and every service (including nginx) seems to work fine.
But the service monitor on the Dashboard says, "webgui" is not started.
And it also cannot be started when I press the arrow.
This is very strange, since I already access it via the web interface (which is not running according to the service monitor).

Addendum:
After adjusting the mentioned optimisation, restarting OPNsense and reactivating the ZenArmor services, there now seems to be a problem with the name resolution again.
It is now no longer possible to search for firmware updates via the OPNsense interface.

No DNS servers are entered under System -> Settings -> General.
Name resolution is done exclusively via Unbound DNS.

If I enter DNS servers under System -> Settings -> General, it is also possible to search for firmware updates if ZenArmor remains activated.


After deactivating the ZenArmor packet machine and restarting OPNsense, the search for firmware updates is possible again. Also without DNS server under System -> Settings -> General. Just as it was before the update.

This time all services (incl. nginx) could be started without errors.

It seems that there are other problems with ZenArmor in connection with the update that cannot be solved simply by adjusting the optimisation 'dev.netmap.buf_num'.

I have made the setting and will now test it for some time.
A Bug Report has been sent afterwards to the supplement.


Besides this Nginx still has problems starting.

The log says:

Code Select Expand

invalid PID number "" in "/var/run/nginx.pid".
and

Code Select Expand

bind() to unix:/var/run/nginx_status.sock failed (48: Address already in use)
bind() to 0.0.0.0:443 failed (48: Address already in use)
bind() to [::]:443 failed (48: Address already in use)
bind() to 0.0.0.0:80 failed (48: Address already in use)
bind() to [::]:80 failed (48: Address already in use)


After some time and manual start-up attempts, nginx can be started and works.

This behaviour did not occur before the upgrade to the new OPNsense version.