Messages

Well yes - if you can match it... but - AFAICT you cannot, as discussed above...

Was not a (visible) issue with FreeBSD <=14.x AFAICT this at least wasn't logged until upstream once again "improved" pf. This causes issues with the other Sense as well...

(Also, there's no way to allow the traffic either, as you've rightly noted.)

Unfortunately, with a particular local ISP, this - even after other specific noise mutings, such as:

Code Select Expand

# grep noise /tmp/rules.debug
block in quick on igb0 reply-to ( igb0 192.0.2.1 ) inet proto udp from {any} to {255.255.255.255} port {10002} label "4ea66722-7f72-4d02-bfe9-341a670b6078" # Reduce log noise
block in quick on igb0 reply-to ( igb0 192.0.2.1 ) inet proto udp from {any} to {255.255.255.255} port {5678} label "379c467f-5758-48dd-9a65-2804f67db023" # Reduce log noise
block in quick on igb0 reply-to ( igb0 192.0.2.1 ) inet proto igmp from {any} to {224.0.0.1} label "c04eab15-ccd4-49af-b7b9-e0515ccb3e45" # Reduce log noise
block in quick on igb0 inet6 proto udp from {any} to {ff02::1} port {10002} label "7b9da65d-e25d-44b7-abaa-d6b157fa4cfb" # Reduce log noise
block in quick on igb0 inet6 proto udp from {any} port {5678} to {ff02::1} port {5678} label "b771a400-9e54-442d-8a94-9adf7e9a0052" # Reduce log noise

takes some 60-70% of the logs. (But at least the live view is sort of useable now, doesn't scroll out of the view faster than you can read, which was the state before implementing the above rules.)

pf should be able to handle "proto 0" syntax, but that's not a GUI option

Not convinced it'd match the traffic with this particular HOPOPT packet header. (Did not investigate the source code, though...)

[without]

Well, I would like to resurrect this topic. My problem is not that it is not allowed, my problem is that it is not allowed but it is impossible to create a manual rule to block HOPOPT without logging. Which is my case leads to tons of log spam. The only option is to disable the default deny rule logging which is sort of suboptimal.

The reason for this being (at least so for as the GUI is concerned) that the protocol is commented out in /etc/protocols (presumably since it conflicts with the IP "pseudoprotocol" 0).

Additionally, the traffic is misidentified in the firewall logs accordingly to the /etc/protocols issue...

Someone with a workaround for this? (Yeah I realize has been basically an upstream problem in libc since forever).

This is the latest one...

[74/74] Upgrading bind920 from 9.20.6 to 9.20.7...
[74/74] Extracting bind920-9.20.7: .......... done
pkg-static: Fail to rename /usr/local/bin/.pkgtemp.named-checkconf.L051g6LB8b9Y -> /usr/local/bin/named-checkconf:No such file or directory

After reboot:

eval: /usr/local/bin/named-checkconf: not found
/usr/local/etc/rc.d/named: ERROR: named-checkconf for /usr/local/etc/namedb/named.conf failed

Had to manually update the bind920 package after OPNsense upgrade finished.

When i block port 53 im loosing dns resolving.

That is super shocking... 😜

I'd say the proper place is /usr/local/opnsense/service/templates/OPNsense/WebGui/php.ini - followed by

Code Select Expand

configctl webgui restart

for changes to have effect.

Reading about the past CrowdSec issue, I know this is probably indicating some service is not cleanly stopping and is holding up the reboot. (Hence why some services stop but it never actually reboots.) With that said, I'm not sure how to identify which service is holding up the reboot.

You can identify those hanging processes with (serial) console. And the crowdsec issue is still there. What I do not understand is why the offending processes are not forcefully killed (SIGKILL) after some timeout period. This is also a long standing issue on OPNsense upgrades.

On another note, I never use the GUI for upgrades or reboots. Just way too unreliable, too many factors that can go wrong there.

Have seen this on multiple boxes. There's something fishy about the dependencies and/or the way pkg resolves them on upgrades.

The purpose is to block doh/dns to be accessed externally from any network on the inside. All resolves should go through internal DNS.

1/ You cannot block DoH (usually port 443) nor DoT (usually port 853) by redirecting port 53.
2/ You cannot redirect DoH/DoT in this way even by redirecting the proper ports - since it breaks the encryption (certificates).

Would suggest reviewing the following, e.g.:
https://developers.google.com/speed/public-dns/docs/dns-over-tls
https://developers.google.com/speed/public-dns/docs/doh

Sigh. So, what is the deal with this change? Regex no longer works at all? "Converting all of my whitelist entries from regex to the actual domain names" is not possible / practical in some use cases, that is the whole point of using the regex in the first place. Or, what's "actual domain name"? Examples - do these still work or not?

Code Select Expand

(.*)?(\.)?akamai.net
(.*)?(\.)?akamaiedge.net
(.*)?(\.)?edgekey.net
(.*)?(\.)?downloads.hpe.com
(.*)?(\.)?gslb-downloads-hpe-com.ext.hpe.com
(.*)?(\.)?gslb-downloads-hpe-com.glb1.hpe.com
(.*)?(\.)?gstatic.com
(.*)?(\.)?api2.branch.io
(.*)?(\.)?cdn.branch.io


I am aware that the point could be made, IPv4 is already one backup, since it's RFC1918...

Do you realize that ULA won't be used at all in dual-stack network?

Might be even the next reboot, not just update. So yes, using the tunables GUI is the way to override those values.

Well, this indeed has been broken upstream. Try with something like

Code Select Expand

hint.uart.0.at="isa"
hint.uart.1.at="isa"


You need a port forward to 127.0.0.1:9200 on the interface where the monitoring host is, not an allow rule on localhost.

Unsure why I would need any port forwarding here, I'm connecting directly to the OPNsense box on the correct port.

Because the packets are not arriving on localhost (loopback) interface at all, as you have observed.

However, when trying from 10.1.1.21, the telnet never connects. Am I missing something obvious here? The 10.1.1.0/24 subnet is in the LOCAL group.

P.S. Making ES listen on wildcard is... crazy. Would really suggest to undo that and do the simple port forward. This post has a proper example of such NAT rule to make services that listen only on loopback accessible over LAN to chosen hosts.  Use 10.1.1.21 for source and 9200 for destination and redirect target ports.

Well, I would suggest undoing your "fixes" and doing a fresh OPNsense re-install.