Messages

If the WAN outage is only a couple of seconds long, even if it happens "frequently", the chances of the gateway pinging catching such flapping interface is somewhat slim, so the WAN quality report will be useless in this case. Would make sense check the NIC interfaces log (or if PPPoE protocol, checking the point-to-point interface logs) for any intermittent errors, timeouts, disconnects, retries, reconnects.

Sorry to deliver the bad news, but documentation is the weakest part of opnsense. So it will be always this forum, where people keep asking the same (or very similar)  questions over and over and over and over. Because the docs repository is both outdated, and lacks proper explanations. Only some basic screenshots are provided, with some non-real-life example config, and no reasons behind. (I am talking only ahout the VPN section, but experience tells that any other sections may be also behind the current state). So you will have to use the unorganized forum topics for the futile effort to find the 1 single post that answers your question.
There are only 2 commercial books that you can buy for money on the market that is dedicated to opnsense. Neither do cover the entire VPN topic in true great deep details, so if you only have problems with the vpn part of opnsense, it will be waste of money to buy them.

Sorry to hijack the thread, just adding my comment:

since CLOG has been deprecated, and as people are upgrading to a newer opnsense releae that uses syslog-ng now, this logging topic will become more and more an issue. Small FW servers with limited storage (especially small SBCs with tiny SSD storage) will easily face storage full issue due to logs.

Maybe. Just maybe: if logging is running for a couple of hours, it would be great to have some form of prediction to be run, that tries to tell how many hours (under extreme conditions) or days of logs can be stored on the storage before it fills up. Calculating log storage consumption delta divided by the sampling period to give a rough estimation. So it becomes immediately known that the settings can stay as is (X number of days of logs to be kept is good enough, or have to increase it to X-Y days).

That APNIC article wasnt really useful. Otherwise said, wasnt really telling the ONE UNIVERSAL TRUTH. For example, the comment section pointed out many different scenarios, where the very low TTL is still a must. The writer of the article was seeing the whole topic through only his own limited perspective, and not considering other factors.

Do not set "minimum ttl" to high. Some server require the requesting the "new" response.

Better set "Serve Expired Responses", so the latency is still very low, but the cache is more accurate.

This "Serve Expires Responses" sounds interesting to me. At least the DNS client could get an answer (an expired answer) but in the meantime Unbound tries to grab a fresh answer from the internet. As the TTL for the obsolete response will be 30 seconds (checked it on Unbound docs site), so if the client tries to connect to the wrong server, the 30second TTL may already expire on the clientside. So the DNS client may try to re-query Unbound. And by that time the Unbound may already have the fresh new valid response. Thats a real-life usage of this feature?

What about the base-23.1.xxx , kernel-23.1.xxx , and packages-23.1.<INSERT SSL FLAVOR HERE> files?

Hello folks!

Is there a way to download the installer packages on another machine, and transfer it to the opnsense machine via USB or similar transfer method. So in case the opnsense machine has no internet access during the update (for whatever reason you can imagine), the update could still be initiated using the files transferred to the opnsense machines filesystem, instead of going out to the internet for the download?

Checking the docs for the Update section did not reveal any such details.

If someone creates a fully filled test matrix of Opnsense 23.1+ IPSEC IKEv1, IKEv2, all the possible combinations of cipher suites, site-2-site and roadwarrior setup: windows 7,8,10 stock OS endpoints, stock Android 11,12,13 + Android stronsgswan app client, I myself would donate to that whitepaper at least 50 EUR without thinking for a second.

I have both books that have been written about opnsense, and both lack the required depth and clarity about Ipsec VPN

Frequently they come with release notes stating which problems are fixed. And I do install these depending on what they are doing. The APU line of devices is so old - what exactly do you expect to still need fixes? Once the device is booted, the BIOS is irrelevant, isn't it? All hardware is reset and initialised by the protected mode OS?

I hope you are just trolling here, and not serious. Have you seen the coreboot open issues on APU? For example if some ACPI entries are wrong in the BIOS, no OS-level sorcery will make it work. And thats just 1 type of problem, why the BIOS must be error free.

The question is, did you open this topic just to clarify a theoretical question? Or you actually have the problem of 100% CPU load while using pppoe and download large files?

[reliably]

The problem is, there is no router-benchmark test, that could reliably tell how many megabits or gigabits/sec a certain CPU could do under Freebsd 12/13, if PPPoE is the WAN protocol.

So the only true option you have, is to buy something that is 2-3-4 gigahertz (translation: overpowered 2-3times, just to be safe), and is actually a very recent microprocessor. In recent I mean: from the past 3-4 years. And be careful! I said not the product itself should be maximum 3-4 years, but the building block CPU/SoC age should be max. 3-4 years. As "some" companies ehem..ehem.. pcengines..ehem are selling a 10 year old AMD Jaguar CPU in their APU2-3-4-5-6-7 product line. At the end of 2022. So the product, like APU7 may be new (because they are sort of hiding the details about APU5-6-7, the public may be in the dark), but the CPU on the board is a rusty p.o.s in terms of routing performance in 2022.

Wow, bad news inbound...

So

• changes are written immediately.
• the "apply" button just reloads the active pf ruleset

That is at least consistent with other subsystems. I wonder if there might ve a UI improvement making this more evident. Not quite sure, yet.

It is alarming and concerning, if such Hero tier members are not clear how the literally most basic function of this firewall product works. Guess how clear it may be for complete beginners.

The VPN-related docs would require a complete re-write since 4-5 years, but dont hold your breath, its not gonna happen.
The Practical OPNsense book by Markus Stubbig is completely useless for any advanced (translation = any, in general) VPN topics either.
OPNsense Beginner to Professional book by Julio Cesar Bueno de Camargo isnt good either.

So, you have to go ahead, and figure yourself out everything VPN-related, the official and unofficial books suck for this "niche" topic.

The 'Local Logging - Disable writing log files to the local disk' option corresponds to the `disablelocallogging` configuration paramter in the back end.  If the option is checked, the logic appears to skip over creating several syslog directives which would result in logs being written to disk; effectively not logging anything.  However, if I'm reading it right, this only appears to occur if 'Disable circular logs' is  unchecked.  I.e. `clog` logs.

So unless 'Disable circular logs' is unchecked, logs will always be written to disk regardless of the 'Local Logging' setting.  This is unlikely to be intentional behaviour.  If your goal is it minimise writes to disk, the current best option is use of '/var RAM disk' (as already suggeted) and a small number for 'Preserve logs (Days)'.

Just among us.. If you made a poll, and asked 100 random opnsense admin, how many would know this is how this logging thing works in opnsense 21.1? As the docs in this topic  are unhelpful, even worse completely misleading the reader, as usual very frequently.