Messages

As it seems, there are now many more no-name NVMEs build into those chinese units, probably because of the price raise in SSD storage.

Under FreeBSD, they can show such effects, because their manufacturers do not care about FreeBSD (and FreeBSD does not care about circumventing NVME protocol problems).

I would change the NVME for a known brand with high TBW.

P.S.: That now made it to https://forum.opnsense.org/index.php?topic=42985, point 14.

Be careful with "new" Unbound host overrides, though: https://github.com/opnsense/core/issues/9587

1. It is correct that normally, with modern adapters, 1504 MTU is always possible, so you usually can add 4 bytes of VLAN tags without further ado. However, this was not the case with early ethernet equipment before the advent of 802.1q and also, for the sake of the argument that you should calculate the VLAN overhead, this will come to an end if you use QinQ. ISP equipment can do anything it likes, too. For example, german ISP Telekom does not like packets larger than 1504, so you cannot apply the guide there and have a net MTU of 1500 bytes - no matter what - I added a disclaimer for Telekom in the guide.

2. What OpnSense does by default with its calculations and/or fragmentation and what the FreeBSD kernel does has changed over time and releases and AFAIK, will again change with 15.x, see this for an example.

For good measure, I like to apply explicit value and even then, the returned values of "ifconfig" sometimes to not reflect the GUI settings.
I mentioned that in the guide by saying: test the effective settings after a reboot and also test what actually works - I have seen the results change from checking directly after I applied them and after a reboot. This is especially true when a "stack" of interfaces like WAN (pppoe) -> VLAN -> physical NIC is in play.


BTW: Testing against a local IP like 192.168.1.1 does not make sense for a WAN optimization, but after having said that, it should always yield 1500 bytes. To enable a WAN MTU of the same size as the usual WAN MTU, to avoid fragmentation with all of its issues is the main goal in the first place. If even your LAN MTU differs, it would be useless. If you get a 1226 byte MTU with the supplied script to a local IP, sometime seems way off.

I think what you can / should do is either use a NIC as passthru or as a bridge member under Proxmox, you cannot have both. So if you have a specific NIC passed thru as ix0, you cannot use it as a bridge member in OpnSense, which is what bridge0 seems to imply.

So it is either ix0 as passthru, which creates the problem that you cannot use it for Proxmox itself or for other bridged VMs or ix0 used as a bridge member for vmbrX under Proxmox and then be able to use it for multiple VMs (including PVE itself and OpnSense LAN).

The only thing I do not know exactly is if you can passthru "half" of the X520-DA2 to use as WAN and use the other half as a vmbrX bridge member for LAN. I think it is impossible, since those two NICs are only PCIe functions, not full devices. Thus, you will be forced to use bot ix0 and ix1 as bridged devices if you want to use any one of them as such.

The guide suggests to use bridged devices, anyway. Partly, that is, because the NIC drivers under Linux support more devices than FreeBSD (and are better supported for some, like RealTek).

I suggest a bridged setup like described here: https://forum.opnsense.org/index.php?topic=44159.0

IDK if you can pass thru each of ix0 and ix1 individually. If so, then you could keep the passthru for WAN and only connect ix0 to the LAN bridge. Within OpnSense, you would then use net0 instead of ix0. If not, you would have to add another bridge for the WAN interface with ix1 and net1.

P.S.: I do not understand where bridge0 comes into play. You only need to create vmbrX on Proxmox with ix0 connected, then attach the WAN interface of your OpnSense VM to vmbr0. Of course that will cause an interface rename from ix0 to vtnetX inside OpnSense, such that you will have to re-assign the LAN interface.

Ich gebe Patrick Recht: Du wirst sehr schnell feststellen, dass Netzwerksicherheit ein komplexes und umfangreiches Thema ist, dem Videos kaum gerecht werden können. Die Macher solcher YT-Videos wollen Clicks für Werbeeinnahmen, keine Gratis-Fortbildung für andere.

Leider ist es sehr oft so, dass Leute das nicht verstehen, und dann hier im Forum aufschlagen, weil sie glaubten "ihr Heimnetz irgendwie sicherer zu machen" und dann feststellen müssen, wie schwierig das dann im Detail wirklich ist. Am Ende sind sie oft frustriert und schieben es darauf, dass OpnSense ein schlechtes Produkt ist, dass niemand bedienen kann. Hier mal ein paar einschlägige Beispiele:

https://forum.opnsense.org/index.php?topic=49930
https://forum.opnsense.org/index.php?topic=49400
https://forum.opnsense.org/index.php?topic=49379
https://forum.opnsense.org/index.php?topic=48959
https://forum.opnsense.org/index.php?topic=47854

Ich sage und schreibe das immer wieder: Es gibt einen großen Unterschied zwischen einem sehr einfach zu bedienenden Endkundenprodukt wie einer Fritzbox (die ist per se auch "sicher") und einer höchst flexiblen, professionellen Security-Appliance wie OpnSense - letztere kann viel mehr, nur muss man dann auch wissen, wie man sie bedient. Wenn nicht, kann das auch schnell mal nach hinten losgehen. Insofern muss man die Lernkurve einplanen - es gibt niemanden, der einen an der Hand nimmt oder das für einen tut.

Das nur als grundsätzliche Warnung und ohne Wertung bzw. Ansehen der Person.

Not only logging, but in particular RRD induces a lot of wear on the storage. It is for this reason you should use storage with high TBW.

However, that should not lead to random reboots unless the storage is really already damaged. You should use a ZFS install, because with that, you would notice if there were bad blocks. I would not trust a firewall system with potentially defective hardware.
 

Der Home Network Guy liegt oft komplett daneben. Beispielsweise empfiehlt er den Einsatz von OpnSense als Transparent Bridge... die Videos sind meist auch veraltet und gehen nicht auf die "europäischen Umstände", wie CGNAT und DS-Lite ein - er setzt IPv4 als (einzig) vorhanden voraus.

Bitte nicht wiederwählen!!!

How did you test? Speedtest, iperf? Multiple streams or one? If you really used FTP, it can normally use only one stream and is heavily limited by BDP and buffer size.

Zwei Hinweise:

a. Realtek: https://forum.opnsense.org/index.php?topic=42985.0, Punkt 6
b. IPv6: https://forum.opnsense.org/index.php?topic=45822.0

@bryanjones: No firewall can do that, unless you configure the client to use a specific proxy. If they claim that they can, they are selling snake oil. The best they could do is to do DNS-based filtering, which is limited to the host part of the URL.

The very principle of traffic introspection relies on breaking up the encrypted traffic, thus presenting a fake certificate to the client which it must trust. If you cannot make all of your clients do that, you are out of luck.

Success is absolutely not guaranteed by these measures,  especially considering that no-name NVME SSD. These errors might go unnoticed under other OSes, so the manufacturer probably does not bother. If you still experience problems, I would suggest changing the SSD for a better one with a high TBW.

That depends on how you define "stable VPN connection". The problem with dynamic IPs is threefold:

1. When one side changes the IP, a standing wireguard connection from the other side will not detect the change and wait forever. This is because Wireguard does DNS lookups only at start.
2. The cron job will detect stale connections and restart them if need be. However, many people do not know this and thus complain here in the forum - partly, they are correct, because the official docs do not mention it.
3. Still, this will induce a drop of connectivity for an even longer period than the actual outage takes, depending on the cron periodicity and how fast the dynamic DNS gets updated.

See this, point 23. Try applying microcode updates and setting the tuneables.

Usually, a firewall is a 24/7 appliance. Booting another OS or application renders OpnSense inactive. Although OpnSense is build upon FreeBSD, you should refrain from using non-supported applications under OpnSense, which would include Docker.

The only way this would work is by using a virtualisation platform to run OpnSense itself alongside other VMs. And in that case, 512 GB seems fairly small. You should also consider that logs, snapshots and updates will fill up your disk in due time. Mine is at 15.5 GB right now.