Messages

@inorx, temperature measurements may be momentary facts. The obsession is over the display.

If the GUI tells me my routers are running in the 35-70 range (actually 50-54 in my case) then why would I care what it "really" is? I know that number will be lower anyway. If the GUI consistently shows 70 or so while CPU and load factors are low then check the thermal connections, ambient air, ventilation. If load, CPU and thermals are all high then the issues are load and performance.

Temperature display is a crude measure. Rarely does anyone need it "accurately" and if you do, there is sysctl dev.cpu but something else will also need cross-checking.

I thought your approach to measurement was interesting, by the way, but in my experience it just does not really matter.

Sorry, I should not have included that throwaway comment. It was clear enough (earlier part of that sentence) by then that the problem had nothing to do with Opnsense but with configuration of the APs, two Mikrotiks. I compared their configurations with each other using a tool I wrote for analysing Mikrotik configs and found an error in one which, possibly because they are bridged, was affecting DNS. All works now. Thank you for your assistance, and my apologies for not being clearer in the last post, albeit I had not actually solved it at that point.

I have verified that everything works normally if I plug a computer directly into the router's IoT port, but not plugged into ports nor via WiFi of the two bridged APs below it.

Therefore the problem should lie with them, ... although they worked under the configuration of the older Opnsense router.....

Thanks for the clarifications @EricPerl, that fits with one of the sensible patterns I considered so no further confusion there :-).

GUI access is available only to LAN and Wireguard now that it is "in production".

I recall reading that post by Patrick, and DoH/DoT are not things I need to use.

While I am not yet marking this as solved, I think that as Shakespeare wrote, the fault dear Brutus is not in the Opnsense but in our devices. I fixed the configuration on Box 3 - it had been misconfigured to refer to itself and not accept what it was told as a DHCP client. The others are working as configured (one is directed through its own BIND). Given that, I can tackle the IoT question again with more confidence.

I do have one supplementary query while I work on that. Given that Unbound listens on all interfaces, how does this interact with DNS queries sent to the internet or to Opnsense? Does it automatically capture everything or are manual rules necessary for redirection?

Every new thing I learn or read about DNS seems to be shadowed by an equal part of new confusion.

After installing the Dec 697 yesterday everything appeared to work until I found I could not pass DNS queries from one interface. I have as outgoing rules
- LAN any to any - this works
- IoT and Servers - pass anything not to local - appears to work for servers, not for IoT, with a further wrinkle.
- Unbound listens on all ports.
- An override in Unbound allows LAN access to the servers.
- DHCP is Kea.
- Crowdsec is off.

I added a prior rule to IoT to allow port 53 to the firewall, trying by a DNAT rule as advised, and as a direct "pass port 53" which also appeared to allow the traffic to pass but without allowing DNS queries.

Testing Servers to see why it worked but IoT did not with otherwise the same rules, I found something really weird.

I have three computers on the Servers net, all connected to the same unmanaged switch. Using SSH into each and trying

Code Select Expand

dig au.archive.ubuntu.com I found the following results:

• Box 1 answered correctly, from 127.0.0.1
• Box 2 answered correctly from root servers
• Box 3 said servfail from 127.0.0.1

These are identical commands on the same subnet through the same rules.

Are the simple rules sound? What sort of configuration might lead to different behaviours or responses? I have "Use system servers" unchecked. The previous router did not use Kea or Unbound but rules are otherwise copied across.

I can try checking what might be configured in the three boxes. Other than that one is MacOS and the other two Ubuntu Linux they should be the same. My query here is firstly to make sure that there is no immediate flaw in the firewall rules model or related configuration that someone is aware might produce this oddity.

Explaining slightly differently, any address A.B.C.x/24 falls in the same subnet regardless of the value of x. Simply changing the value of C, as suggested, will suffice as will changing A as you propose, staying within RFC1918. Playing with a couple of the different subnet calculators on the web, with different presentations, is quite useful for understanding IPv4 addressing. 

According to Protectli, the interface ending in zero is the WAN. I'm also able to connect to the web GUI through a connection on the LAN port so I think the assignments are correct.

Your IP assignments as described are incorrect or else they are not as described.

Your final sentence to EricPerl touches on this. If your ISP router is distributing 192.168.1.1/24 then change your LAN IP range away from that. Bridging the ISP router might be better but that is not a current problem. Your described IP ranges are.

The "same problems" as whom or what? What are you trying to do, or what is your test setup?

What is your Opnsense setup? Default? Ports? Subnets? Rules? Some detail is needed.

USB-to-ethernet connectors have some reputation for unreliability.

Your IP ranges are not distinguished. They are in the same range, 192.168.1.0/24

Did you choose specifically during configuration to set up WAN on igc0, LAN on igc1? By default they are the other way around.

I suggest you leave everything else, such as NAT, as defaults until you resolve the above.

Most likely, correct errors in your DNS server.

What is it anyway? What is the relationship of your DNS server to Opnsense? Information is lacking here.

@enlil, you are already running from USB if you can get to the position of installing. Therefore, Opnsense works on your system. The errors are characteristic of SSD problems, possibly cable or the controller. Start by checking cables and seating. As implied by Patrick, a BIOS tweak to slow down data rates may enable it to run, or your system might just be a bit old and may even die shortly.

In any event going backwards with the software is very unlikely to improve compatibility, while it will negate the security purpose of a firewall.

Set up 2FA from scratch again, in trial mode only. See whether that testing works on a new instance. If clocks are right on both devices then the code string is wrong on one or the code is at the wrong end. I am not actually suggesting you got the latter wrong, it is just a remaining available cause.

I have had no problems at all with 2FA through upgrades from 24.7 to 25.1.3.

Ich habe @JeGrs Kommentare gelesen und stimme als relativ normaler Nutzer, der kein Experte ist, grundsätzlich zu. Ich bin kürzlich mit Unbound auf Kea umgestiegen. Beides ist nicht schwierig. Ich sah keinen Grund, DNSmasq zu verwenden, brauche keine automatische Registrierung und kann Dinge nach Bedarf benennen. Mein Eindruck ist, dass mit dieser Kombination potenzielle Probleme einfacher sind und ich mehr Kontrolle habe.

(übersetzt)

@user88, that clarifies to a point. For the other half, have you tried with a fresh, purely default Opnsense?