1
24.1 Legacy Series / Re: WiFi Calling - I need to prioritize this traffic
« on: July 11, 2024, 12:11:43 am »
AFAIK it uses an IPSsc VPN. Check UDP ports 500 and 4500.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
24.1 Legacy Series / Re: OpenSSH CVE-2024-6387
« on: July 04, 2024, 06:59:34 am »
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
[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
3
24.1 Legacy Series / Re: IP is Behind CGN - How to Get a Public IP to WAN Using VPS/OpenVPN for Port Fwd?
« on: July 01, 2024, 07:50:39 am »
IPv6 is not CGN'ed, coz unlike IPv4, there is no shortage of IPv6 address blocks.
4
General Discussion / Re: Help me understand search domains
« on: June 29, 2024, 12:06:47 pm »
Obviously I do not have many Apple devices in my network then 
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.
[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
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]
#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
5
General Discussion / Help me understand search domains
« on: June 29, 2024, 11:31:30 am »
Hi,
maybe you can help me understand search domains. I don't seem to get it.
Here's the relevant description of my setup:
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.
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?
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]
#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 msIn 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?
6
24.1 Legacy Series / Re: WAN stops working randomly?
« on: June 03, 2024, 09:06:19 pm »
Next time check in System > Routes > Status, if you have a default route set
7
24.1 Legacy Series / Re: UnboundDNS (and dnsmasq) spontaneously stopped working today
« on: June 03, 2024, 03:12:24 pm »
If you suspect a bad unbound config, did you run unbound-checkconf? (https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound-checkconf.html)
8
24.1 Legacy Series / Re: suricata and pppoe vlan11 tagged fiber / WAN dont work
« on: May 30, 2024, 09:38:29 am »
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.
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.
9
24.1 Legacy Series / Re: suricata and pppoe vlan11 tagged fiber / WAN dont work
« on: May 29, 2024, 06:40:40 am »
Also NAT and intrusion detection systems are no friends.
10
24.1 Legacy Series / Re: bufferbloat drives me crazy
« on: May 28, 2024, 08:32:01 am »
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
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
11
24.1 Legacy Series / Re: Unbound DNS reporting stops randomly - 24.1.6
« on: May 25, 2024, 10:56:48 am »
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.
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.
12
24.1 Legacy Series / Re: Unbound stats stop working
« on: May 22, 2024, 03:20:29 pm »
similar thread: https://forum.opnsense.org/index.php?topic=40509.0
13
24.1 Legacy Series / Re: Unbound DNS reporting stops randomly - 24.1.6
« on: May 18, 2024, 08:42:50 am »
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
Restarting the unbound service helps for a while until is breaks again.
Code: [Select]
error: SERVFAIL <some.redacted.domain. AAAA IN>: exceeded the maximum number of sendsRestarting the unbound service helps for a while until is breaks again.
14
24.1 Legacy Series / Re: flowd_aggregate process burning high CPU in OPNsense 24.1.6-amd64
« on: May 08, 2024, 08:03:49 am »
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)
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)
15
24.1 Legacy Series / Re: IPv6 ULA with NPT, when WAN is Dynamic
« on: April 26, 2024, 09:49:44 am »
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...
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...
Pages: [1] 2