Messages

AFAIK it uses an IPSsc VPN. Check UDP ports 500 and 4500.

iXSystems has released a new TrueNAS version 13.0-U6.2 [1] with the FreeBSD fix back ported to 13.0 [2]


[1] https://www.truenas.com/docs/core/13.0/gettingstarted/corereleasenotes/#130-u62
[2] https://ixsystems.atlassian.net/jira/software/c/projects/NAS/issues/NAS-129828?jql=project%20%3D%20%22NAS%22%20ORDER%20BY%20created%20DESC

IPv6 is not CGN'ed, coz unlike IPv4, there is no shortage of IPv6 address blocks.

Obviously I do not have many Apple devices in my network then :D

Thanks Patrick. I do understand that use case, but in such a case you could explicitly configure the client resolver to make use of the ndots option. The ndots option in the resolve.conf[1] defines the dots threshold for appending the search domain. The default is 1 meaning "if there are less than 1 dots, i.e. none, then append the search domain". In a scenario like yours, setting ndots throughout the network to 2 should help. Do Macs have a resolve.conf? For Windows there's a registry entry to configure[2] the dots threshold.

Still, that does not help to explain the invalid queries. The nts.ntstime.de query was not done by an Apple device. It was done by my OpnSense instance, which should use the ndots default value of 1.

Code Select Expand


#cat /etc/resolv.conf
domain home.lan
nameserver 127.0.0.1
search home.lan


[1] https://man.freebsd.org/cgi/man.cgi?resolv.conf
[2] https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.DNSClient::DNS_AppendToMultiLabelName

EDIT: inline links changed coz not working

Hi,

maybe you can help me understand search domains. I don't seem to get it.

Here's the relevant description of my setup:

• I'm using OpnSense and have a home domain home.lan (I explicitly tried to avoid .local used by mDNS to not get into some sort of trouble)
• OpnSense hosts a network-facing, resolving and caching Unbound instance.
• The Unbound instance handles all the resolving of dynamically assigned devices for home.lan.
• The Unbound instance delegates resolving of all statically assigned devices to a local Bind instance via a stub zone.
• The local Bind instance is private and provides home.lan records to Unbound for all devices with static IPs.
• DHCP is providing the search domain home.lan via option 119.
• DHCP is providing the domain home.lan via option 15.
• Devices with static IPs have the search domain and domain manually set to home.lan (that includes the OpnSense instance)

What is a search domain?
As I understand it, search domain is a convenience feature that "interpolates" host names into FQDNs. It tries to detect, if a given domain string is a proper FQDN or just a host name. In the latter case it creates a FQDN by appending the search domain. This turns a mere host name into something known to DNS that can actually be used for addressing.
For example: Entering the host name opnsense into a ping will "interpolate" into opnsense.home.lan which is a proper domain name known to DNS.

Code Select Expand

#ping -v opnsense
ping: sock4.fd: 3 (socktype: SOCK_RAW), sock6.fd: 4 (socktype: SOCK_RAW), hints.ai_family: AF_UNSPEC

ai->ai_family: AF_INET, ai->ai_canonname: 'opnsense.home.lan'
PING opnsense.home.lan (172.22.24.254) 56(84) bytes of data.
64 bytes from 172.22.24.254: icmp_seq=1 ident=30591 ttl=63 time=0.757 ms
64 bytes from 172.22.24.254: icmp_seq=2 ident=30591 ttl=63 time=0.658 ms
64 bytes from 172.22.24.254: icmp_seq=3 ident=30591 ttl=63 time=0.693 ms
^C
--- opnsense.home.lan ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2032ms
rtt min/avg/max/mdev = 0.658/0.702/0.757/0.041 ms

In my case the A record of opnsense.home.lan is provided by the private Bind instance to the Unbound instance, which will cache it and provide it to the requesting client. All good and well.

Now, my issue is with the host name detection mechanism of the search domain feature. By default the search domain is appended, if there are no dots in the given domain string. The reasoning being: No dots means host name (cf. host name opnsense vs. domain name google.com).
However, that detection does not seem to work well. I can see multiple instances in which nonsensical DNS queries were created by appending the search domain. Here's an example from a time server lookup of my Chrony instance trying to lookup nts.ntstime.de.home.lan:



Can anyone explain, why I see such invalid search-domain-appended queries from clients? Why is the search domain appended to the proper domain nts.ntstime.de in this instance?

Next time check in System > Routes > Status, if you have a default route set

If you suspect a bad unbound config, did you run unbound-checkconf? (https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound-checkconf.html)

Intrusion detection systems need to track the flows. If you do address translation then sources or targets of flows are rewritten. The original flow is terminated and replaced. Intrusion detection systems typically only see one leg of the entire communication. Either the original flow leg or the replaced, new flow leg. But in either case they keep on missing half of what's going on.
Feel free to read the documentation for details. It's all there right in the "Choosing an interface" chapter: https://docs.opnsense.org/manual/ips.html#choosing-an-interface".

PS: There is a reason why many admins hate NAT. You have to jump a lot of hoops and deal with heaps of BS just to keep using the old IPv4 address.

Also NAT and intrusion detection systems are no friends.

Unfortunately, CAKE is not available for Opnsense.
The best we got is FQ-CoDel. It needs a bit of setup, though. Obviously you need to set the pipe bandwidth. It should be sufficient to set it to a value 10% less than the line rate. If your line rate is varying, then try to choose a conservative average rate in the beginning.
In order to get good results, you may also need to set the FQ-CoDel quantum value to your WAN MTU. You can get it from your default route in System > Routes > Status (assuming Path MTU Discovery is working).
Also, setting the FQ-CoDel target for very slow (like mobile) or very fast connections (like fiber) maybe be needed. In order to obtain a target value for your WAN connection, you can use mtr(1). Make sure the line is unused and let it run for a while to get a decent sample count. Use the average ping of the first hop as your target value.

(1) mtr -bz -i 5 -o LSD__NAW__M_X__ -L 55555 1.1

Interesting. I can remember an instance when Unbound was entirely broken. Not only just not reporting, but also not responding. Restarting the Unbound service via UI did not work and repeatedly failed with a service timeout error.
So, I used the CLI and I did a ps aux | grep unbound and killed all Unbound processes manually. Interestingly there were multiple flock processes which I killall'ed. Once all processes were killed, I could start Unbound in the UI, everything was fine again.
So, I indeed believe there may be an edge case in which the lock handling with flock does not work. I guess there should not ever be multiple flock processes.

similar thread: https://forum.opnsense.org/index.php?topic=40509.0

I have these reporting stops in which the Unbound page is empty also with 24.1.7. Log file does not contain anything except for

Code Select Expand

error: SERVFAIL <some.redacted.domain. AAAA IN>: exceeded the maximum number of sends

Restarting the unbound service helps for a while until is breaks again.

I have a FW2B with a weaker dual core CPU and I also see periodic spikes of flowd_aggregate,py. However, here it's just using one of the cores for about 3 seconds, not constantly.
Maybe resetting or repairing the newflow database helps to fix your aggregation issue. Check Reporting > Settings > Reporting Database Options > Repair Netflow Data (resp. Reset Netflow Data)

Out of curiosity: May I ask why one would want to map GUAs to ULAs via NPt?
NPt seems to be the little brother of NAT, which is the bane of IPv4. I see no good reason to bring this flaw to IPv6 that was explicitly designed to overcome this flaw...