Topics

Hi,

I'm currently experimenting with IPv6-only networks. I might soon get a DS-Lite connection and consider finally getting rid of IPv4 (except for some niches) and run an IPv6-preferred network.
For testing I have NAT64 set up with the Tayga plugin and DNS64 deployed via Unbound. This setup works ok. The fact that many clients on Android, iOS and recent Windows support 464XLAT by now helps to mitigate issues with IPv4 literals that can not be addressed by DNS64. DHCP option 108 is already available and PREF64 support is on the way (I think radvd 2.20 supports it already, only UI support is missing). All things considered, I believe NAT64 could be a viable IPv4 transitioning solution. There is really only one single issue with my tests: IPSec

Why is IPSec important? Well, other than the fact that most corporate VPN solutions use IPSec, the main reason IMHO is VOWIFI aka Wifi Calling. VOWIFI allows handheld devices to extend the mobile network via a WIFI network. This is achieved by establishing an IPSec connection to an Evolved Packet Data Gateway (ePDG) of the mobile provider via the internet. This essentially brings mobile services to where no mobile reception is. I'm sure most of you know Wifi Calling. IMHO a killer feature not to be missed.
The IPSec mode used by the VPN connection to the ePDG is tunnel mode with the ESP protocol and UDP encapsulation (NAT-T). Unfortunately, the ePDGs seem to be using IPv4 exclusively (see https://www.netify.ai/resources/mobile-gateways). I do not know why there is still no support for IPv6, even though mobile providers feel the pain of IPv4 address space running out. I also do not know of any plans to change that in the near future. So one can assume Wifi Calling with IPv6 will require NAT64 for the time being.

Now, the good thing is, NAT64 in general should be able to support IPSec with the ESP protocol (unlike IPSec with the AH protocol). However, NAT64 via Tayga does not. In my tests I was not able to use IPSec and in extension Wifi Calling. As far as I can tell Tayga simply does not have support for protocol 50 (ESP) - only 1 (ICMP), 6 (TCP) and 17 (UDP). I believe support for rewriting ESP headers could just be added, but it's not there for now.

TL;DR: NAT64 via Tayga is incomplete.

Which brings me to the actual question: What is the current state of "native" NAT64 support on OpnSense? Are there any plans to support NAT64 besides the Tayga plugin? I could not find anything in the roadmap about it.
I'd assume using Jool is out of the question being a Linux kernel module.
FreeBSDs own IPFW has support for NAT64. The original PF on OpenBSD has support for NAT64, too. The FreeBSD port of PF however does not have NAT64 support AFAIK, because it was forked before NAT64 support was added.
PFSense seems to have gotten native support for NAT64 recently, but I do not know how it is implemented there.

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?

[uname -a]

Hi,

I have trouble setting up Netflow. It seems to not support VLAN interfaces nor PPPoE interfaces, which is basically all I have. None of my interfaces seem to be able to collect any data. My cache tab is empty.


root@cepheus:~ # uname -a
FreeBSD cepheus.home.lan 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 stable/23.1-n250396-d34cd428508 SMP amd64

root@cepheus:~ # df -H
Filesystem                  Size    Used   Avail Capacity  Mounted on
/dev/gpt/rootfs             239G    2.0G    218G     1%    /
devfs                       1.0k    1.0k      0B   100%    /dev
/dev/gpt/efifs               268M    1.8M    267M     1%    /boot/efi
devfs                       1.0k    1.0k      0B   100%    /var/dhcpd/dev
devfs                       1.0k    1.0k      0B   100%    /var/unbound/dev
/usr/local/lib/python3.9    239G    2.0G    218G     1%    /var/unbound/usr/local/lib/python3.9

root@cepheus:~ # cat /usr/local/etc/netflow.conf
#
# Automatic generated configuration for netflow.
# Do not edit this file manually.
#
netflow_interfaces="vlan0.1.12 vlan0.1.23 vlan0.1.3 pppoe0 "
netflow_egress_only="pppoe0  "
netflow_version="9"
netflow_int_destination="127.0.0.1:2055"
netflow_destinations="127.0.0.1:2056"
netflow_active_timeout=1800
netflow_inactive_timeout=15

root@cepheus:~ # cat /var/log/flowd.log


root@cepheus:~ # ll /var/netflow/
total 100
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 dst_port_000300.sqlite
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 dst_port_003600.sqlite
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 dst_port_086400.sqlite
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 interface_000030.sqlite
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 interface_000300.sqlite
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 interface_003600.sqlite
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 interface_086400.sqlite
-rw-r-----  1 root  wheel  12288 Feb 23 19:14 metadata.sqlite
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 src_addr_000300.sqlite
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 src_addr_003600.sqlite
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 src_addr_086400.sqlite
-rw-r-----  1 root  wheel   8192 Feb 23 19:14 src_addr_details_086400.sqlite

root@cepheus:~ # /usr/local/etc/rc.d/netflow restart
setup vlan0.1.12
ngctl: send msg: Invalid argument
error vlan0.1.12: cannot create netflow node for vlan0.1.12
setup vlan0.1.23
ngctl: send msg: Invalid argument
error vlan0.1.23: cannot create netflow node for vlan0.1.23
setup vlan0.1.3
ngctl: send msg: Invalid argument
error vlan0.1.3: cannot create netflow node for vlan0.1.3
setup pppoe0 [egress only]
ngctl: send msg: No such file or directory
error pppoe0: cannot create netflow node for pppoe0


I have named the VLAN interfaces according to this pattern vlan0.<interface-id>.<vlan-id>
with interface-id 0 for igb0 and interface-id 1 for igb1. I believe that should be fine.

Any help is appreciated.