Messages

Ok, strange: When I got the name resolution finally back running, OPNsense installed updates to bind and haproxy (single version step). Now everything is running again. No idea why these were missed in the full upgrade...

Anyway, I made a health check now afterwards and it complains about:

Code Select Expand

py37-markupsafe has a missing dependency: python37
py37-markupsafe has a missing dependency: py37-setuptools
py37-markupsafe is missing a required shared library: libpython3.7m.so.1.0

but I do not know if this is actually a problem. Everything seems to run fine again.

So, problem is resolved. Thank you very much for the quick reply and keep up the good work!

Cheers, Stefan

Hi folks,

after the update to 25.1.4_1 (I think from 25.1.2) BIND is not starting anymore.

In system.log I only see:

Code Select Expand

<13>1 2025-03-28T19:08:58+01:00 SERVERNAME root 33135 - [meta sequenceId="1"] /usr/local/etc/rc.d/named: ERROR: named-checkconf for /usr/local/etc/namedb/named.conf failed

If I try to start binaries manually via shell, I get:

Code Select Expand

ld-elf.so.1: Shared object "libisc-9.20.7.so" not found, required by "named-checkconf"
ld-elf.so.1: Shared object "libisc-9.20.6.so" not found, required by "named"
ld-elf.so.1: Shared object "libdns-9.20.7.so" not found, required by "named-journalprint"

So there might something be mixed up in the package with the binaries and their libraries...
It would be great if this could be fixed as I prefer BIND vs. Unbound.

TIA & best regards,
Stefan

Hi vOoPtNa,

is this still an issue with 21.1?
I had a lot of trouble with IPsec-tunnels due to MTU and MSS, and the best solution I came up with was using a routed tunnel with setting MTU=MSS=1350 on the VTI interfaces to actually get the tunnel fragment the packets *before* they enter the tunnel (aka prefragmentation).
This needs some additional pf-rules (on IPsec and the VTI interfaces) to let the fragments and reassembled packets pass (reassembled packets do not seem to carry over the pass flag), but now the traffic is mostly stable (well, there's still a checksum issue, but this is something else...)

This might have been already fixed with FreeBSD 13.0 -> PR: 255432 (https://reviews.freebsd.org/R10:055c55abefbe19fe46a56894595af9c9dad7678c)

But I am not sure and would like to verify by checking the sources. Can someone point me in a direction how and where to find the source that is actually used for OPNsense (by version)?

Hi everyone,

I have a strange issue:

I finally found a configuration that allows for pre-fragmentation of packets sent through routed IPsec Site-2-Site VPN. All my packet captures show that IP packets are correctly fragmented *before* being encapsulated (which is important in my network setup). On the target site, packets seem to get reassembled and then sent out via LAN interface - but they have in incorrect ipv4-Checksum and get dropped by final recipient.

To be precise: The checksum value for the reassembled packet is taken from the first fragment, corrected by +0x100 for TTL. [see packet #3 in LAN_filtered.pcap (csum 0xf23e) vs. p#5 in VTI_filtered.pcap (csum 0xf13e)]

What is even more strange:
On the first reassembeld packet, everything works. Starting with the second, it fails. after approx 15-20 secs -> works again (maybe some internal reset). Non fragmented packets are not affected.

I attached a packet capture with the relevant packets. It contains two pings needing fragmentation (first works, second does not), and two pings without fragmentation (both work).

I guess this is not a directly OPNsense related bug, but may reside in the FreeBSD/HardenedBSD ipsec stack. If so, shall I file a bug report somewhere else?

Best regards,
   Stefan

PS: Checksum offloading is deactivated in all involved OPNsense instances.
PPS: pre-fragmentation is gained by simply setting a smaller MTU on VTI interface. I can provide more info on network setup on request if this is not directly forwarded to OS issues.

Same here!

If I tracked it correctly, GMX rejects emails send without correct SPF information.
The activation mail is sent from 'reply@opnsense.org', but in ID and reply-to 'www-data@www.opnsense.org' is used, thus  spf validation fails.

@ForumAdmins:
Could you fix this by either:

• Correct reply-to / id info in mails
• Simply copying the txt-record for SPF to www.opnsense.org

TX, Stefan