Messages

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.

Yes, actually your impression is correct. The limited rate after the duplicated rules obviously was limited to 9 log entries per second, because I originally had 9 rules and imposed an 1/1 limit on them. I just want to see indications as to what is happening in the logs. I still can look at the counters if I want to see how many requests come in.

I cannot say for sure how many requests per second were there at the time of attack and I also think many may have been dropped because the storage could not keep up. It is a 1 Gbps connection, but with just port probing, that may still amount to a few thousand requests per second, each of which has a significant log impact. I cannot really say what has happened, because obviously the filterlog process was out for several hours (there is also a gap into log file history on one day), such that not even remote logging shows anything. As a matter-of-fact IDK if the CPU load was only a side effect.

Logging for default deny is off here.

It seems to me the rule should be applied regardless if the log rate limit has been reached. Obviously, without logging.

While that would be desirable, pf does not work that way today, so I made it work.

My question is actually three-fold:

1. Can anyone think of a cleverer way to make it work without using duplicated rules?
2. Would there be a way to have the desired behavior for block rules (i.e. "rate-limit logging without affecting rule matching"), probably as a feature request for OpnSense?
3. Should there be a more prominent web UI warning about this "unexpected" behaviour for block rules?

And no, I do not want to use syncookies for functional reasons - also they would not fix the problem: state table exhaustion is not the issue, it is the mere logging that is throttling the firewall.

AOC brauchen pro Port 1-2,5W, Passive DACs maximal 0,1W. Wo soll das sparen?

Die Vorteile liegen bei der maximalen Länge der Leitung, Störfestigkeit und galvanischer Entkopplung, wie korrekt bemerkt mit wesentliche höheren Kosten.

Und wenn Du gute NICs und moderne Switches hast, wären selbst längere 10 GbE-Leitungen nicht mehr so viel schlechter bei 1 Watt pro Port.

Realistischerweise also: Im Serverraum DAC für kurze Verbindungen, wenn lange Leitung benötigt bis ca. 20m: 10GbE oder 2.5GbE, wenn längere Leitungen und Verkabelung "alt": optische Kabel.

Recently, I had a problem when some of my friends told me that out voice chat was choppy. When I investigated, I found my OpnSense at 100% CPU. That turned out to be due to 7 WAN block rules for various blocklists and an ongoing DDOS attack.

I had logging enabled for those rules and the log was constantly being written to. I could not even reliably use the web UI.

This made me think about how to rate-limit the logs. Apparently, with 26.7.2, there is now max-pkg-rate from pf available.
So, now, you can create two block rules, one with logging enabled, quick block and "Max packet rate [packets]" = 1 and "Max packet rate [seconds]" = 1 to have a rule that matches at most once per second and logs and another quick block rule without logging and without rate limits immediately following that.

By using that, you still have (rate-limited) logging, but without the risk for a totally overwhelmed OpnSense.

Alas, you need two rules, because the first one will not match any more when the rate limit has been exceeded. Would there be a better way of having such a thing (i.e. eat the cake and still have it)?

P.S.: Allowing rate-limiting on block rules is a potential security hole, IMHO: When you use that without thinking, the block will not be applied when the rate is too high, i.e. block rules can be circumvented by just hitting more frequently at the target....
I guess the original idea was to do this for pass rules only and rate-limiting those on the side.

I believe that, in some respects, they have come very far, but I think we are talking about two different things. I certainly expect an AI to outperform me at individual tasks — otherwise it would not be much of a tool. What I do not expect it to do is decide what my goals should be or which goals are worth pursuing.

Asking clarifying questions, decomposing a problem or comparing solution strategies neither requires nor indicates that kind of agency. Those are extremely useful capabilities, but they still operate within a goal and context supplied by somebody else.

I tend to regard current AIs as collections of remarkably powerful, but uneven, cognitive capabilities rather than thinking entities pursuing goals of their own. If they ever became better than us not merely at solving problems, but at deciding which problems ought to be solved and why, then we would indeed have a rather different problem.

I also do like the "OPNsense Science Fiction and Philosophy" wording, and maybe robotics really is further behind than "thinking", so that might be an alternative. There are still everyday tasks that even the most advanced robots struggle to perform reliably, while a six-year-old does them without thinking — such as picking up a key, orienting it correctly and opening an unfamiliar lock.

That is an interesting and difficult question - I am grateful I do not have to ponder that out of sheer necessity.

What I see now is that LLMs have some specific advantages over humans. For example, the more capable models can keep a much larger amount of information in their working context at once - something I have found much less useful with smaller local or free models.. They can therefore do tasks "in memory" for which I would need pencil and paper, or several intermediate steps. They can also access information on the Internet much faster than I can.

So I basically use them as tools that can be guided and directed by me - and much more efficiently and cheaply than a team of human assistants ever could.

For people doing intellectual work, I would argue that the important thing is to develop the skills needed to make the best use of these tools. That being said, it still takes a lot of expertise and problem-solving ability to direct them properly - at this point, they still need expert guidance and supervision.
My best guess would be that the gap between good and bad engineers will probably widen. There may be fewer people doing this kind of work, but those who remain in demand will be highly skilled and very productive.

So I would invest less in learning one particular new technology, and more in strengthening problem-solving skills: learning how to frame a problem, break it down, question assumptions, move between different levels of abstraction and determine which problem actually needs to be solved. Domain expertise certainly helps, but these skills transfer remarkably well between domains.

Quite often, the important question is not how to perform a task correctly, but whether it is the right task to perform in the first place. Those decisions should not be left to managers alone, and AI is certainly not suited to making them either.

That is something I have been practising for decades. Story of my life. Even without the AI part.