Messages

[@Tubs]

@Tubs
have you tried not to select CAs in TLS:Trusted Certificate in Upstream config page?
should work if upstream cert issued CAs is in trusted store on OPN and nginx is happy on cert check

I could not reproduce anymore.

One day after I went back to to nginx 1.19 opnsense automatically updated again to version 1.20. But it is running now. I guess the fix already was implemented.

The issue popped up again when I updated to 21.1.
Yes, when I untick "check trusted certificate" all is working again.

Since the upgrade to 21.1-rc...my https-reverse-proxy does no longer start.
[...]
Somebody with a good idea?

Yes, have a look here in 20.7. Same for 20.7.8
https://forum.opnsense.org/index.php?topic=20989.0

Nobody, who can give me a hint if this network topology is correct?

I do not look for detailed configuration help. I only want to know if this way of routing will work and if it is the best way to do so.

[@Tubs]

@Tubs
hmm. a little weird. I think that for this it was necessary either to press "check for updates" or execute "# opnsense-revert os-nginx".

It is possible that I have done this. If so, for a different reason. I cannot remember. But in every case I did not confirmed any upgrade process.

[@Tubs]

@Tubs
have you tried not to select CAs in TLS:Trusted Certificate in Upstream config page?
should work if upstream cert issued CAs is in trusted store on OPN and nginx is happy on cert check

I could not reproduce anymore.

One day after I went back to to nginx 1.19 opnsense automatically updated again to version 1.20. But it is running now. I guess the fix already was implemented.

I have exactly the same issue. OpnSense updated to 20.1.8 and nginx is not starting anymore.

Code Select Expand

2021/01/20 22:03:14 [emerg] 95587#100595: SSL_CTX_load_verify_locations("/usr/local/etc/nginx/key/trust_upstream_228ce5a1-*****.pem") failed (SSL: error:0B084088:x509 certificate routines:X509_load_cert_crl_file:no certificate or crl found)

The file mentioned in the log file is not existing. But I have no glue how to figure out where it should belong to. I have a couple of upstream and a couple of server defined. So far nothing suspicious detected. But I have no idea where to search.

opnsense-revert -r 20.7.7 os-nginx

Dies this fix it?

Yes. In my case it helped. Nginx is running again.

[move the routing between the network "LAN" and "WAN" to an external 10 GBit L3 switch]

Hello,

currently my home network with a hand full of VLAN is set-up with in that way that opnsense is doing all routing between the sub-nets. All devices are connected to one L2 switch. But since I upgraded a part of my home network to 10 Gbit, I now have a bottleneck between the networks I call "LAN" and "DMZ". My opnsense is a small box with 1 GBit ports only, but good enough to handle the traffic to and from internet.

Three goals I have:
(1) I would like to move the routing between the network "LAN" and "WAN" to an external 10 GBit L3 switch (Ruckus 7250). For all other networks the routing can stay on the opnsense box. Only few traffic needs to get routed that is related to those.
(2) I would like to utilise the available 3 physical ports (A2, A3, A3) on the opnsense box as much as possible.
(3) I would like to minimize the overhead on the opnsense box generated by VLAN tagging or LAGG.

My ideas are:
- run LAGG over all three ports and run one VLAN trunk to the switch with all networks in
- run one VLAN / VLAN trunk on each of the three ports and manually distribute the VLAN / subnets acc. expected traffic
- as shown on the sketch: one separate gateway and route for LAN and DMZ, directly connected without VLAN or LAGG. All other packed in one VLAN trunk. No need for LAG or VLAN on the networks with highest traffic.

Any disadvantages by going with the last one?
Better ideas?

Code Select Expand


  opnsense                               L3 switch

       A1 --------X WAN

                GW1 - 192.168.1.10/30
       A2 -------------------------------- B1 - LAN: 192.168.40.0/24   

                GW2 - 192.168.1.20/30
       A3 -------------------------------- B2 - DMZ: 192.168.50.0/24

                 VLAN trunk
       A4 -------------------------------- B3 |--- VLAN 10: 192.168.10.0/24
                                              |--- VLAN 20: 192.168.20.0/24
                                              |--- VLAN 30: 192.168.30.0/24

Since 20.7.4 it is better again. Still more swap is used than before. But no service is stopping any more.

Not hidden - it is on almost every page on the bottom.

Vielen Dank!
Ich habe den Knopf gefunden, hatte aber niemals diese Funktion damit verbunden.

Muss man nicht. Reload button klicken reicht.

" Reload button"?

Thank you. I found the "reload" function in the console menu and will try out the next time.
But button? Somewhere hidden in the GUI?

Die Config kann weniger und wird daher vielfach als einfacher angesehen.

HAProxy ist in OPNsense mehr oder weniger ein Load Balancer und der nginx kommt mit zusätzlichen Funktionen wie WAF, UDP Lastverteilung, Web Server, ...

Danke.

Bei Regentagen werden ich mal wieder HAProxy für den reinen Zweck des Reverse Proxy (Thema dieses Threads) testen. Ich hatte damit gestartet und bin verzweifelt.

Nginx läuft bei mir. Mich ärgert nur, dass ich OPNsense jedes Mal neu starten muss, wenn ich etwas an der nignx-Konfiguration ändere. Ohne Neustart der gesamten Firewall werden die Änderungen nicht aktiv, auch ein Neustart von nginx hilft nicht.

HaProxy ist dein Freund.

HAProxy wird als reverse proxy unter OPNsense meist empfohlen, nginx seltener.
Mal die Funktion load balancing ausgeschlossen, welche Argumente sprechen für HAProxy statt nginx?

Frage: welches ist der sinnvollste Weg, diese Weiterleitungen zu den jeweiligen Subdomains einzurichten?

Um mehrere Webserver hinter der Firewall über Port 80 und 443 verfügbar zu machen würde ich so vorgehen:
- öffentlich erreichbar --> reverse proxy: z. B. plugin HAProxy oder nginx
- nur über eigene Geräte und sensible Daten --> VPN: z. B. openVPN, IPSEc, WireGuard

Ich selbst verwende nginx und WireGuard für diesen Zweck.

Your rules are wrong.

What is wrong?
Can you please be specific?

Firewall rule to point your mailserver to another DNS or install a forwarder to you ISP ones on the mailserver direct. And for client use the unbound? Would that be an idea?

Yes, that is more or less what I already described in my first post as possible solutions.
(1) resolver on mail server directly
(2) point mail server to other DNS. My idea additional bind on OPNsense.

As "split functionality" of unbound act as resolver resolver for one host and act as DoT forwarder for everything else is not possible, that's it.