Messages

Hmm. Ich habe hier zwei Fragen:

1. Was heißt "OPNsense blockiert ausgehend, so Bedarf das eigentlich ein Umdenken."? Das ist eigentlich nicht so vorgesehen. Normalerweise blockt oder erlaubt man bei OpnSense nur mit "in" Rules. Oder wie meinst Du das?

2. Wenn Du nur 3 VLANs hast, dann helfen Dir die "Bereiche" oder "sortingnetze" doch nichts, weil innerhalb eines VLANs jeder mit jedem frei kommunizieren kann?

Ich mache das eigentlich so, dass ich zunächst jedes VLAN mal gegen RFC1918 abschotte (außer den höher privilegierten VLANs, also z.B: Management) - die dürfen alles. Abgesehen davon dürfen die aber auch jedes Ziel, also ins Internet. An sich ist es ziemlich egal, ob wir über ein IoT-VLAN sprechen, ein normales Client-VLAN oder ein Gast-VLAN - ohne Internet geht meist sowieso nichts.

Danach muss ich mir nur noch überlegen, welche Dienste ich habe, die trotzdem geöffnet werden müssen, dass mache ich mit PASS-Regeln davor.
Sofern es zentrale Dienste wie DNS, NTP o.ä. sind, richten die sich sowieso an "This Firewall" und können für alle Netze oder Gruppen (ich habe eine für die "weniger privilegierten VLANs") in den Floating Rules freigegeben werden.

Sind es spezielle Services, wie z.B: Zugriff auf einen Fileserver im LAN, definiere ich einen Alias für die erlaubten Clients und einen für die zum Service gehörigen Ports und erlaube es per Floating PASS-Regel. In den Interface-Regeln sind eigentlich nur die Block-RFC1918 und die Pass-Any-Regeln, abgesehen natürlich von WAN-Regeln.

Zur Organisation kann man Categories nutzen, danach lässt sich die Anzeige auch filtern, wenn das zu viele Regeln werden.

Neuerdings gibt es auch die "Automation"-Sektion, das habe ich aber noch nicht genutzt.

Do you actually see blocked websites or are these just random log entries? One that you posted is from Google and it has a FIN-ACK state.

Therefore, potentially, you see artifacts from QUIC traffic - I see those, too.

You can test if you allow HTTP3/QUIC traffic and see if the test triggers those log entries. Wait a bit, it may be that the TCP stream must be closed to cause a log entry.

Yes, #10 regarding the CPU speed? I tried an updated Xeon E3-1260LV5 CPU with no change. Or did I miss something in that post?

So, did you actually try the tips in the link I posted in #1?

No. follow this link and look in point 10 in the first posting. There is more than one tip w/r to low speeds.

Yup! I use LXCs or VMs on Proxmox, which can both be placed on VLANs that are separate from Proxmox's control plane. By strictly using reverse proxies, the default route is mostly irrelevant, because the caller is always the internal IP of the reverse proxy. You have to take steps to pass the remote caller IP via HTTP headers, in order to be able to know who the original caller was in the backends.

And my Docker installation is in a separate VM. To be exact, I have two Docker VMs, one for containers reachable from outside and one internal only.

Damn. Than I need to create a VM. (I wanted to skip this part since its one more thing to learn from zero, when the only goal is to get my website server up and running again 😅)

What I do not quite understand then is how you separated your docker containers in VLANs, like you said you did? Patrick says that is not possible when running containers under Truenas?

Have I summarized it correctly? 🤔 (I write like this to see if I understand it or if I have broken logic)

Yes. With the "other" approach I described in my first answer (i.e. the usual OpnSense one, not the one involving Cloudflare), you would install the reverse proxy on OpnSense itself and then direct the backends to different webservers on isolated VLANs. You would not use a separate Nginx reverse proxy, but one on OpnSense itself, like Caddy or HAproxy (both have HOWTOs in the tutorial section of the forum).

Logically, both do the same thing: You terminate the TLS traffic in a reverse proxy (your own or using cloudflare), then the traffic is passed to an isolated webserver that can do no harm if hacked. Cloudflare just happens to provide these topics:

1. Certificate issuance.
2. "Finding" your backend (which would otherwise be done via dynamic DNS)
3. Reverse proxying and tunneling the traffic to your end.

That looks fine. You do not need to separate cloudflared from nginx, but it does not hurt, either.

IDK if TN directly supports docker containers, if so, keep in mind that true VMs provide a better isolation than lightweight containers, like Docker, LXC or their likings.

So, did you actually try the tips in the link I posted in #1?

You first said you did not get an IPv6 on WAN, but now you get one, that is O.K.

I do not see what is wrong with that gateway. It may well be a LL adress like fe80::f2:5d09 and the gateway monitoring says it can be pinged, so what is the problem?

Please show your WAN configuration page and expand the gateway column in the pictures. Also, please show your LAN addresses.

If you have a managed switch with both DAC and 2.5 GbE ports, you can use a DAC to connect the switch and your OpnSense and use the 2.5 GbE port to connect to your ONT. By using a VLAN you can separate the WAN traffic from your other (V)LANs. That is even possible with just one DAC connection between the switch and OpnSense, because you can use it for all VLANs.

Kind of a "router on a stick" configuration.

On the switch, you often can set a fixed speed for ethernet ports and the DAC connection is 10 Gbps anyway.

An alternative to this is an OpnSense device with 2.5 Gbps enthernet ports (and potentially, SFP+ for future-proofing), like I use one.

1. The forum does support adding images, but only via the "reply" function, not with "quick reply".
2. Take a look at this. Some ISPs only hand out a prefix, which you can use now on WAN.

At these speeds, problems can occur for a multitude of reasons, bad cabling being one of them. As I said, some devices cannot auto-negotiate, thus they may fall back to 1 Gbps.

But no, I do not know if anything can be done via firmware. I found that especially ethernet SFP+ transceivers are problematic - for this reason and also, because they get very hot with higher speeds. I use SFP+ only with DAC, or if I needed longer cabling, I would use optics transveivers.

I could not even use GPON SFP transceivers in a meaningful way, because most host adapters do not support HSGMII mode with 2.5 Gbps (or they cannot mix 10 and 2.5 Gbps speeds, like the two ax port on the DEC750, so I was capped at 1 Gbps there, too.

Even if it was, @ProximusAl is using a pure optic SFP+ module which always has a 10 Gbps link speed.

Your problem is different: You use a transceiver that can theoretically handle different Ethernet speeds on the link side, yet always reports 10 Gbps to your host. Also, you cannot force a link speed on your side because of this, so you are stuck with whatever link speed is automatically negotiated.

Even if both sides can theoretically do 2.5 Gbps over ethernet, sometimes it is not auto-negotiated. This is even true for some non-SFP+ ethernet adapters, like the Intel X550, where 2.5 Gbps must be forced.

Alas, you probably cannot force the specific speed (2.5 Gbps) from the ONT side of the link, either.

Sometimes, using the os-realtek-re plugin (vendor driver) helps, but intel based network cards are the better choice.

If the cap is exactly at 1 Gbps, it is more likely that the SFP+ module connects only at 1 Gbps to the ONT. It happens often that SFP+ modules connect at their highest specified speeds to the host (in your case 10 Gbps), yet use lower speeds on the real link. For example, some SFP+ slots only support 1/10 Gbps, so only those can be reported. The real link speed is up to the SPF+ module and you cannot choose it from the host.

That is true of the ax and ix drivers.