Messages

At least they finally did something, and responded on bugzilla.
My last bug report really isn't worth their time... https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280615

Can confirm that 25.7rc2 fixes the issue for me.

Thank you guys, this made me question my network admin skills and/or sanity ;)

@meyergru: Thanks for the tip.
I've updated to 25.7rc2 and indeed the workaround fix from OPNsense team works.

I'm happy that there is a logical explanation, as I was just questioning my sanity :)

I use to deploy OPNsense on AlmaLinux with KVM, so I can backup / restore the whole VM in a couple of minutes.
Got very good results for years. Ping me if you need some advices (especially when not using PCI-passthrough for performance).

Hello,

I'm facing a real WTF situation and really could need some advice here.
I have a OPNSense FW (25.1.10), and cannot wrap my head around my issue.

Randomly, pings to 8.8.8.8 or 1.1.1.1 get blocked by the firewall.
From the same LAN subnet, some computers can ping, others can't.
After a while, other computers can't ping, and some that couldn't now can.

When looking at the firewall logs, the ICMP packets that get blocked are processed by the same rule as that passes other ICMP packets.
When clicking on the rule link, the window closes since the rule isn't found (see the attached screenshots).

In order to outrule some factors, I've:
- Disabled Zenarmor
- Disabled Suricata
- Disabled Crowdsec
- Marked my default gateway as always on (no monitoring)

When I ping 1.1.1.1 or 8.8.8.8 from the firewall itself, of course both respond.

I've also tried to check the Disable reply-to wan setting in firewall>settings>advanced.
I've checked that I don't have any special routes to 1.1.1.1 nor 8.8.8.8

This happened already with 24.7 series as far as I can remember.
I've just updated 25.1.10 to 25.1.11 and a computer that could ping 8.8.8.8 but couldn't ping 1.1.1.1 can now ping 1.1.1.1 but can't ping 8.8.8.8 anymore.
I've also exported my opnsense config file and searched for those IPs in order to make sure I didn't forget anything.
The only entry I found for 1.1.1.1 is for query forwarding in unbound.

I'm totally puzzled as why this is random.
I'd be grateful for any clue where to search for.

Thank you.

I've also encountered multiple (and strange) resolve errors with unbound like the following:

Code Select Expand


2024-09-18T13:46:40 Error unbound [54445:2] error: SERVFAIL <somedomain.tld. A IN>: all servers for this domain failed, at zone somedomain.tld. upstream server timeout
2024-09-18T13:43:36 Error unbound [17415:1] error: SERVFAIL <xx.xx.xx.xx.in-addr.arpa. PTR IN>: all servers for this domain failed, at zone 64.92.188.in-addr.arpa. no server to query no addresses for nameservers
2024-09-18T13:43:36 Error unbound [17415:0] error: SERVFAIL <xx.xx.xx.xx.in-addr.arpa. PTR IN>: exceeded the maximum nameserver nxdomains
2024-09-18T13:43:30 Error unbound [17415:3] error: SERVFAIL <xx.xx.xx.xx.in-addr.arpa. PTR IN>: exceeded the maximum nameserver nxdomains
2024-09-18T13:33:04 Error unbound [17415:3] error: SERVFAIL <85.21.107.40.zen.spamhaus.org. A IN>: exceeded the maximum nameserver nxdomains
2024-09-18T13:32:26 Error unbound [17415:2] error: SERVFAIL <somedomain.tld. A IN>: all servers for this domain failed, at zone somedomain.tld. from 194.0.34.53 no server to query nameserver addresses not usable


After reading alot of documentation, one guy said that ISPs may tamper with DNS.
In my setup, I've got 3 internet providers, so I configured Unbound to use WAN1 only, then WAN2 then WAN3.
While doing dns requests, I noticed that WAN1 provider tampered (probably) with DNS since both WAN2 and WAN3 produced good results, but WAN1 didn't.

Hopefully this might help some other people.

I've also encountered multiple (and strange) resolve errors with unbound like the following:

```
2024-09-18T13:46:40   Error   unbound   [54445:2] error: SERVFAIL <somedomain.tld. A IN>: all servers for this domain failed, at zone somedomain.tld. upstream server timeout   
2024-09-18T13:43:36   Error   unbound   [17415:1] error: SERVFAIL <xx.xx.xx.xx.in-addr.arpa. PTR IN>: all servers for this domain failed, at zone 64.92.188.in-addr.arpa. no server to query no addresses for nameservers   
2024-09-18T13:43:36   Error   unbound   [17415:0] error: SERVFAIL <xx.xx.xx.xx.in-addr.arpa. PTR IN>: exceeded the maximum nameserver nxdomains   
2024-09-18T13:43:30   Error   unbound   [17415:3] error: SERVFAIL <xx.xx.xx.xx.in-addr.arpa. PTR IN>: exceeded the maximum nameserver nxdomains   
2024-09-18T13:33:04   Error   unbound   [17415:3] error: SERVFAIL <85.21.107.40.zen.spamhaus.org. A IN>: exceeded the maximum nameserver nxdomains   
2024-09-18T13:32:26   Error   unbound   [17415:2] error: SERVFAIL <somedomain.tld. A IN>: all servers for this domain failed, at zone somedomain.tld. from 194.0.34.53 no server to query nameserver addresses not usable
```

After reading alot of documentation, one guy said that ISPs may tamper with DNS.
In my setup, I've got 3 internet providers, so I configured Unbound to use WAN1 only, then WAN2 then WAN3.
While doing dns requests, I noticed that WAN1 provider tampered (probably) with DNS since both WAN2 and WAN3 produced good results, but WAN1 didn't.

Hopefully this might help some other people.

Found where to add the fsfreeze hook, see https://github.com/opnsense/core/issues/7681

Nevertheless, there is a bug in qemu-guest-agent that doesn't launch thaw script properly :(

So I finally tried a last solution posted on a FreeBSD forum https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165059

Setting the following in `/boot/loader.conf` solved the issue:

Adding parameters to /boot/loader.conf

Code Select Expand


#hw.vtnet.X.tso_disable="1"
hw.vtnet.tso_disable="1"
hw.vtnet.lro_disable="1"
#hw.vtnet.X.lro_disable="1"
hw.vtnet.csum_disable="1"
#hw.vtnet.X.csum_disable="1"


I've jumped from remote uploads at 20-30Mbits to a whopping 300Mbits ^^
I've previously tried this with ethtool without success.
Also, I had to reboot in order for the changes to take effect.

You could check in the system tunables where you have `net.inet.tcp.tso` setting.

Have you selected Zenarmor native routed L3 native netmap driver ?

I've added the transfer tunnel network into the allowed IPs on each peer, and voilà, everything works as expected.
Sorry for the noise, should have found that myself.

Thanks for your help @chemlud

Nope, transfer net isn't in allowed ips, and of course this makes perfect sense, since wireguard would just deny the tunnel ips themselves.
I'll check that once I am onsite and report back.
Thanks.

I've got a any any firewall rule on both sides on the wireguard (group) interface.
What broader firewall rule am I supposed to create ?

Loading suricata rules creates a python process that indeed maxes out CPU, but should only be slow, not freeze your OPNSense instance.

This loading process also consumes alot of RAM, you should check whether this is your culprit.

From my experience, running OPNSense from too lower end hardware isn't the best.

I've got a couple of J4125 (2Ghz 4 cores) boxes running OPNSense, and they needed an extra cooling fan just to not go through the roof, on top of slowing down throughput when scaling down CPU frequency.

last but not least, don't run OPNsense on cheap realtek NICs, which could explain why zenarmor isn't happy with the offloading.

Okay, I actually retried my whole config.

Automagic user creation from LDAP when connecting to OpenVPN works, unless you set "Enforce local group" in OpenVPN config like I did.

So this is basically a security issue, since if I remove a LDAP user from a let's call it "VPN GROUP" on the LDAP server, the user still can connect, since the user already exists on OPNSense.

I have setup an extended query like `&(memberOf:1.2.840.113556.1.4.1941:=CN=VPN GROUP,DC=domain,DC=local)(objectCategory=person)` but still can connect to OpenVPN once I've removed a user from the ldap "VPN GROUP".

[EDIT] After removing the recursive ldap attribute for memberOf, adding / removing users from VPN GROUP limits it's ability to VPN connect like it should. [/EDIT]