Messages

Outbound NAT is legacy, its rules should be migrated to SNAT and it will eventually go away completely (use the search):

https://forum.opnsense.org/index.php?topic=52261.0

The Outbound NAT page is essentially only there because the setting for Automatic, Hybrid, Manual and Disable NAT was still there, which is admittedly (and obviously) confusing. The last changes duplicated the mode setting to the SNAT page as well, so you can ignore Outbound NAT and have no rules left there (i.e.: migrate them to SNAT).

That is the same. With one of the last updates, "Outbound NAT" has been renamed to the more common "Source NAT". If you still see Outbound NAT in your firewall menu, you either use BE or are way behind with your updates.

You are using the wrong documentation. Please read the first paragraph of the initial post in this thread and follow the linked swanctl Roadwarrior documentation. The guide you linked describes the old/legacy IPsec configuration, which is why those menus do not exist in your installation.

So you now expect OpnSense CE (which is free) to invest in interoperability for Surfshark (which you presumably pay for)?

You are assuming that "hardware" must be faster than "software". That is not generally true.

If OPNsense itself runs as a VM on that host, the traffic has to pass through a VM anyway, so adding physical NICs and an external switch only adds another network path.

Only if OPNsense is a separate physical firewall does the traffic need to leave the host in the first place.

In either case, I would start with virtio + a Linux bridge and only change that if measurements show an actual problem.

I can only tell you how I am doing that kind of thing with PVE (which also uses KVM, so this should be similar enough):

I have one bridge vmbr0 connected to a physical ethernet adapter that connects to the "real" network and it also has the IP of the PVE host.
A second bridge interface vmbr1, is VLAN-aware and is purely virtual, in that it has no physical NICs attached to it at all.
For each VM, I create a separate VLAN X with a an associated subnet, say 10.0.X.0/24. The VM X itself has 10.0.X.2/24 as its IP address and 10.0.x.1 as gateway and DNS server.

I use one OpnSense VM that has its virtio "WAN" attached to vmbr0 and thus gets an IP on my LAN. It also has a virtio "VLANBRIDGE" interface, off of which I define "VLANX" interfaces accordingly with VLAN X and IP address 10.0.x.1/24.

Each of the VLANXs is allowed to access the internet, but not RFC1918, so it cannot access either LAN devices or other VMs.

On the other hand, I can create rules that allow access from the "WAN" (aka LAN) to each VM (or the whole 10.0.0.0/16 range).

You can use such a setup in a datacenter or at home, like described here: https://forum.opnsense.org/index.php?topic=44159.0

[you]

@talespin: Or you should update more often to keep up with patches for known vulnerabilities, like most people do. That way, you will only have to do small. incremental steps in case something changes w/r to functionality. This is the reason why you cannot expect an automatic mechanism that spans more than one version in one big leap.

There is also the possibility to backup your configuration, install fresh and import your configuration. However, that may fail for the same reason.

See: https://forum.opnsense.org/index.php?topic=42985.0, point 10.

That being said: You probabaly will not see more than 8 GBit/s even when you actually use more than one stream.

Nein, wieso? Die HDD wird doch nicht angesprochen von der CPU. Oder leuchtet die HDD-LED bei Dir schon, wenn die HDD Strom bekommt, z.B. in einem externen Gehäuse? Was ist denn das für eine?

Die Maschine/CPU tut gar nichts, wenn kein funktionierendes RAM drinsteckt - insbesondere spricht sie die SSD nicht an.

Bei einem Desktop oder guten Mainboard würde es eventuell Piepstöne oder eine Diagnose-LED für den Fall geben. Der Bildschirm bleibt jedoch dunkel, weil die CPU-Grafik RAM braucht für die Anzeige.

Ohne RAM kommen diese Systeme nicht hoch, deswegen ist der Test mit "nur SSD" sinnlos. Ich tippe auf das RAM.

Das eigentliche VPN ist wohl weniger ein Problem. Nur müssen sich die Endpunkte finden.

Im konkreten Fall wird es da eventuell zwei Probleme geben:

1. Mindestens eine Seite der Verbindung (zu Hause) hat vermutlich eine dynamische IP. Die Gegenseite kann den Endpunkt also nur per DynDNS finden.
2. Beide Endpunkte liegen selbst hinter NAT-Routern, sind also von der Internet-Seite aus nicht so einfach zugänglich. Übrigens schließt das m.W. IPsec weitgehend aus. Heutzutage ist allerdings gerade zwischen zwei OpnSensen Wireguard ohnehin der De-Facto-Standard.

Um Problem Nummer 2 zu lösen, muss ein Port-Forwarding auf einem der Front-Router eingerichtet werden, dass den Zugriff auf den VPN-Port der OpnSense ermöglicht.

Es geht also um die Frage, welche Seite die VPN-Verbindung aufbaut - das Ziel muss die Verbindung per Port-Forward durchleiten und möglichst per statischer IP oder per DynDNS-Name erreichbar sein. Das setzt auf der Ziel-Seite voraus, dass man:

a. Den Front-Router entsprechend konfigurieren darf (z.B. bei der Firma)
b. Den Front-Router überhaupt entsprechend konfigurieren kann (also: hat er Möglichkeiten, DynDNS zu pflegen? Kann man eine Portweiterleitung einrichten?)
c. Der Front-Router nicht selbst wieder geNATed ist (also z.B. an einem CG-NAT-Anschluss hängt). Falls ja, müsste man per IPv6 arbeiten, was z.B. für DynDNS meist schwieriger ist.

Die Quell-Seite der VPN-Verbindung ist unkritischer, dort muss nur eine ausgehende Verbindung zugelassen sein.

Du kannst zumindest prüfen, ob die SSD einen Kurzschluss verursacht, wenn Du die abziehst. Ins BIOS kommst Du dann ja auch ohne. Und wenn die es nicht ist, kann ja eigentlich nur das RAM fehlerhaft sein.

Es sind ja insgesamt nur 4 Komponenten:

1. Netzteil
2. CPU/Mainboard
3. SSD
4. RAM

Wenn 1 & 2 schon getauscht sind und wir davon ausgehen, dass Du keinen Kernschrott geliefert bekommen hast, dann können es nur 3 oder 4 sein.

The RTX3080 alone was ~35W, which was reduced to 5W, because I use the IGD now. Also, there seemed to be some peripherals than would not let the chipset enter deep sleep states. My soundbar is 5W and the 39" monitor has 40W. I have the 14700K only for being better selected chips, it is not overclocked, but rather PL2 reduced to 125W. The net effect is that the whole system is also way quieter.

And now for the end of the story:

Last week, I found that my old system (Ryzen 5900X, X570S mainboard, 2x16 GByte DDR-4, RTX3080) used way too much power. Including my monitor, it took 180W from the wall at idle. Therefore, I changed the CPU to an I7-14700K and the mainboard to a B760 variant and kept the rest of the components. I had made that switch from AMD to Intel before with my PVE server and had much less power consumption afterwards.

When sifting through my parts cabinet, I found the RTL8127 again and for the sake of less consumption, used that instead of the Asus XG-C100C. I thought I could safely do that because I suspected the combination of my old mainboard and the adapter to be problematic.

After the rebuild, the system was at 120W, all was well and for the fun of it, I did a test copying data off a samba share and checking its sha256 before and after. Much to my disbelief, the result was defective in ~1 of 2 cases!

After a bit of testing the new platform, I found that the only other remaining commonality was the RAM and went to test it, only to find that both of my RAM strips were defective! Luckily, these were G.Skill Trident Z Neo with a lifetime warranty bought in 2019 and I got an RMA acknowledged.

Alas, during the test, my Windows 11 system was botched again and I had to do a repair install, which cost me 2 days. Now everything works.

I have not had RAM problems in the last 20 years or so and would never have suspected that.

So, the Realtek RTL8127 is all good and working now. I changed the first port to point here...

If your observations are correct, that makes two problems:

1. OpnSense cannot resolve DNS names.
2. Your former ISC DHCP does not work any more.

Obviously, the former version was not 26.7-based, but probably much earlier. There were several serious changes from, say, 25.x to 26.7., including which DHCP is preferred.

Thus, you essentially have two options:

a. Install the os-isc-dhcp plugin to restore your ISC DHCP setup - while it is EOL, this will give you local subnets again, solving point 2.
For point 1, I would first try to chec if "nslookup www.google.com 8.8.8.8" from the CLI of your OpnSense works, verifying WAN access. Then you can try to use Google DNS for OpnSense and Unbound.

b. Follow along the DNSmasq instructions from the docs, preferably on a fresh install to rule out other/older DNS or DHCP services blocking DNSmasq. If you switch DHCP, your reservations or internal DNS names will not be carried over automatically with either DNSmasq or Kea, anyway. There are external scripts to do that, but with a normal installation, it is probably better to do it manually.

I would prefer to start from scratch in your situation, because even the firewall and NAT rules have been changed. The jump from your old version to the current one is too far to justify the migration effort. I think it is easier to start fresh, maybe you can jot down or print out the relevant old rules and DHCP reservations first.