Messages

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.

Some sites do not respond to ping and some not to pings with older versions than 26.7.1. Other than that, take a look here:

https://github.com/opnsense/core/issues/10540

Especially this comment: https://github.com/opnsense/core/issues/10540#issuecomment-5001904923

Please take this as serious advice rather than a technical review: you need to reconsider the way you are using AI.

What you attached is not a finished piece of documentation. It is a largely unedited AI work log containing repeated scripts, superseded versions, contradictions, abandoned theories, corrections and unresolved issues. It even includes the AI's extravagant praise of your work. That praise is not peer review (rather an echo chamber), and copying it into a public forum is frankly rather bizarre.

An AI will happily describe every failure as an important discovery, every added workaround as further hardening, and every increase in complexity as evidence of sophisticated engineering. It has no reliable sense of when the entire approach has become too fragile and should be abandoned. Providing that judgement and the stop criterion remains your responsibility.

The length of AI-generated output does not make it a valuable work product. Before asking other people to read it, you need to understand it yourself, decide which claims you can personally defend, independently verify them, discard the obsolete material and explain the remaining result coherently in your own words.

If you cannot reduce the essential design, its assumptions and its known failure modes to a few readable pages, you are not yet ready to publish sixty pages about it. Forum members should not be expected to act as editors and reviewers of an unfiltered AI session.

My sincere recommendation is: stop adding to this document, step back from the AI dialogue, get some sleep and only then reconsider your working method before continuing.

Sorry to have to be so rude, but:

This post is almost a piece of modern art in its unspecificity.

"Latest update" without version numbers; "process 50512 terminated" without naming the process or quoting the message — and a PID that became meaningless seconds later; "routing refusal" as a paraphrase instead of the actual log entry; "successful negotiation" without saying which phase; and WAN being "unassigned" without showing the interface assignment or configuration.

Not a single actual log line is included, although the logs supposedly contain the relevant clues. There is no information about the previous and current OPNsense versions, hardware or virtualisation, interface and driver, ISP, PPPoE configuration, or what exactly "unassigned" is supposed to mean.

The description even contradicts itself: the connection fails, negotiation succeeds, and WAN is unassigned.

What exactly do you expect anyone to advise on? Please provide the raw information instead of an unspecific summary of it. As it stands, this is not a diagnosable problem report; it is merely a description of the fact that you have a problem.

Did you work through the network "hardware" section in the guide?

Does the USB network adapter show full link speed? 9 Mbit/s could either be 10 Mbit/s on the ethernet side or an inferior USB link, like with USB 1.1.

Configured like what? There are bazillions of possibilites, like pass-through or virtio andy many more.

See:

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

and:

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

Again: A router is not a switch - nor an access point. If your Netgear router is in router mode, OPT1 is probably connected to the WAN port of the Netgear, with NAT and firewall of that enabled. If it is configured that way, clients behin the Netgear are provisioned by it and get different IPs from your LAN.

True AP mode would mean that the Netgear would act as an AP only and the WAN port should probably be left unused.

I can only guess here about typical beginner problems. Every specifiy part of your setup matters, which is why we typically ask you to draw a network plan and show every bit of the configuration. Often times, while you do that, you will notice what's wrong by yourself.

A router is not a switch.

Conceptually, OPT1 and LAN are two different interfaces. So it all depends on how you configure them. What you probably want is to bridge both physical ports to one logical interface, not have to different interfaces with different subnets.

This is explained here.

If that is something different than you actually want, you should probably read this first.

[special]

I suggest you to read:

https://forum.opnsense.org/index.php?topic=42985.0, especially point 3

and

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

if you have not done so already.

On a side note: "VLAN 1" is special - on some switching platforms, it denotes the "untagged" VLAN, on some, it doesn't. So be sure that your switch, your Proxmox installation and OpnSense are in sync about what "VLAN 1" means in terms of bridge view, logical and physical interface views, respectively. Also check that port 5 has PVID 20; making it an untagged member of VLAN 20 only controls egress tagging.

You will find that you have chosen an environment with the maximum amount of potential complications. If you do not have an advanced level of networking knowledge, you will have a steep learning curve ahead - and I do not mean that condescending, but as an unbiased early warning, only considering the fact that this was your first posting here. What I mean by that is that I doubt that there is a step-by-step guide and an LLM will probably be of little use, either, especially if it is a free or local variety with limited capabilities.