Messages

Sorry the normalization documentation was merged and updated a bit too early and reflects the upcoming version already.

Ah! :) Thanks for the clarification.

Hi,

I am reading https://docs.opnsense.org/manual/firewall_scrub.html

Firewall ‣ Settings ‣ Filter <- does not exist
Firewall ‣ Rules [new] <- does not exist
Select the Match action <- how and where? I do not see any field where I can select a Match action

Is this documentation for a previous version? Is there documentation for 26.7?

Ok. But this is a route, right? Looking at the documentation https://man.freebsd.org/cgi/man.cgi?query=route

Code Select Expand

    Routes have associated flags which influence  operation  of  the  protocols
    when sending to destinations matched by the routes.  These flags may be set
    (or sometimes cleared) by indicating the following corresponding modifiers:

    -xresolve    RTF_XRESOLVE  - emit mesg on use (for external lookup)
    -iface    ~RTF_GATEWAY    - destination is directly reachable
    -static    RTF_STATIC    - manually added route
    -nostatic ~RTF_STATIC    - pretend route added by kernel or daemon
    -reject    RTF_REJECT    - emit an ICMP unreachable when matched
    -blackhole RTF_BLACKHOLE  - silently discard pkts (during updates)
    -proto1    RTF_PROTO1    - set protocol specific routing flag #1
    -proto2    RTF_PROTO2    - set protocol specific routing flag #2
So what we're using here is -blackhole. Can we use -reject instead?

There's another and - in my opinion - better approach for preventing traffic with private destination addresses from being routed to the ISP:
Create null routes for all private address space. This will blackhole all private destination networks for which no higher priority routes exist. No firewall rules needed.

TIL. Thanks.

Is it possible to reject the blackholed traffic instead of dropping it?

Blocklist für was? Eingehenden Traffic? Ausgehenden Traffic? Was willst du erreichen?

If you only need a fallback in case AdGuardHome is unavailable, better set up a second instance on another machine. You can use adguardhome-sync to synchronize your settings.

However, this will get you unreliable statistics as your clients will randomly pick one of your instances. I have solved that with keepalived. Set up a virtual IP for keepalived on both machines and use that IP address as your DNS server. If the main instance goes down, the virtual ip will move to the second machine and that instance will answer the queries.

This is neither a consumer product nor a commercial solution. This is the community edition of an enterprise firewall. If you choose to use it, you need to educate yourself and read the release notes of every update before pressing the button. Community support relies on users doing their homework. Expecting enterprise-grade stability and active hand-holding without carefully reading the changelog misses the point of a community edition.

If you're not able to read and understand release notes before updating critical components, OPNsense may not be the correct solution for you. Consider switching to a consumer product.

When I look at the statistics and it says 'cleared: 1970-01-01T01:00:02', what does that mean?

It means it was cleared before time synchronization took place. 1970-01-01 is the beginning of Unix time.

Install the os-vnstat plugin.

Is there a recommended site to follow (like RSS) or something similar so I can keep up to date?

OPNSense will show a changelog on every update. Read it.

If you want to read release notes outside of the UI, there are these places:

https://forum.opnsense.org/index.php?board=11.0
https://opnsense.org/blog/

Thanks for the quick fix! Had the same issue, luckily was able to recover by disabling and re-enabling the WAN / PPPoE interface after reboot.

He mentioned a secondary drive so I assumed a mirror.

Just because it's a ZFS mirror doesn't mean both drives are bootable. The installer leaves the EFI partition on the second drive unformatted, so if you don't create the filesystem and copy the bootloader over manually, it won't boot when the primary drive fails. Learned that here.

Seeing the same hier with translation target ?.

Code Select Expand

nat log quick on pppoe0 inet proto udp from 192.168.100.21 port = 47141 to any keep state label "PCP MAP b939ca8f21f0c995ee240a6e" rtable 0 -> ? port 47141
rdr pass log quick on pppoe0 inet proto tcp from any to any port = 47141 keep state label "PCP MAP 0f926edb0b878a8d23d54b58" rtable 0 -> ? port 47141

So is the issue with the missing ip address going to be fixed or is this whole feature abandoned?