MadaMada
@madamada@snac.void.my
The IT-Notes blog is now served by the 1 euro/month #NetBSD VPS, too.
@stefano Pretty amazing that your blog on a 1€/month VPS has so much faster loading times than almost all of the websites I usually visit, but then I guess that's a given, because my browser doesn't have to download hundreds of megabytes of JavaScript and run hundreds of trackers in the background. 😁
There are 3 approaches to this .. the ndproxy approach, the NAT66 approach and the vnet jail approach. They all work depending on scenario..
I'll be doing some more tests just to catch any surprise cases that might pop up.. I'll maybe then write a simple guide to get this done all ways 🙂
Tayga CLAT on FreeBSD 14.3-RELEASE with NDPROXY
CLAT as part of 464xlat as defined in RFC 6877 is meant to be running on an IPv6-only host.
The Setup
pkg install gmake gcc ndproxy-3.2.1403000_1
Get the tayga git repo
mkdir /root/staging ; cd /root/stagingPrepare tayga configuration
git clone https://github.com/apalrd/tayga.git
cd tayga
gmake
cp tayga /usr/local/bin/
mkdir /var/db/tayga
chown nobody:nobody /var/db/tayga
cat /etc/tayga.confReplace 2001:db8:1:1:: with your own IPv6 prefix. I am using my own NKP prefix here for NAT64. You can use one from here
tun-device clat0
ipv4-addr 192.0.0.2
ipv6-addr 2001:db8:1:1::65
#prefix 64:ff9b::/96 # Well-Known Prefix
prefix 2001:db8:64:64::/96 # Network-Known Prefix
data-dir /var/db/tayga
wkpf-strict no
map 192.0.0.1 2001:db8:1:1::64
log drop reject
Write a script to configure the clat0 interface and it's routes and save it as /root/bin/routes-clat.sh
#!/bin/shMake the script executable. Next setup tayga and ndproxy to start on boot..
ifconfig clat0 inet 192.0.0.1/29 192.0.0.1 up
ifconfig clat0 inet6 -ifdisabled
route add default -iface clat0
route -6n add 2001:db8:1:1::64/127 -iface clat0
cat /etc/rc.conf.localDownload the rc script for Tayga
# TAYGA (CLAT)
tayga_enable="YES"
tayga_interfaces="clat0"
# NDPROXY
ndproxy_enable="YES"
ndproxy_uplink_interface="vtnet0" # host interface
ndproxy_downlink_mac_address="xx:xx:xx" # host mac address
ndproxy_uplink_ipv6_addresses="fe80::xx:xx:xx" # gateway link-local address
ndproxyconf_exception_ipv6_addresses=""
curl -O https://buster.xpath.my/tayga/rc.d-tayga.txtNow that everything is in place, time to start and test it..
mv rc.d-tayga.txt /usr/local/etc/rc.d/tayga
chmod +x /usr/local/etc/rc.d/tayga
service tayga startTest with the ping command. Example output will look like this:
service ndproxy start
sysctl net.inet6.ip6.forwarding=1
sysrc ipv6_gateway_enable="YES"
ping -c3 1.1.1.1With curl:
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=37 time=216.021 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=37 time=216.013 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=37 time=215.861 ms--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 215.861/215.965/216.021/0.073 ms
curl -kI https://8.8.8.8/NOTE: If you are using NAT64/PLAT address from nat64.net, some of them might block ICMP. If so test with curl instead. Latency-wise, it is better to run your own NAT64 or use one that is geo closer to you. You can either use #Jool or #Tayga for NAT64.
HTTP/2 302
x-content-type-options: nosniff
location: https://dns.google/
date: Sun, 22 Jun 2025 06:41:58 GMT
content-type: text/html; charset=UTF-8
server: HTTP server (unknown)
content-length: 216
x-xss-protection: 0
x-frame-options: SAMEORIGIN
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
Please test and provide feedback. Thanks 🙂
@madamada On the translation side everything seems to be working, but on the routing side, I'm completely stuck ... :(
@madamada On a FreeBSD 14.3-RELEASE VM. I think I'm doing something wrong with the networks in rc.conf / tayga.conf / my firewall though. In particular, I don't know where in my network I have to the NKP (FreeBSD VM? Firewall?) and so on.
You setup rc.conf as usual, on the Tayga side, they use a different address under the same IPv6 subnet..
Update:
On the firewall, pass quick on clat0 all or check with tcpdump..
During my tests, I disabled the firewall just to rule out if there was an issue, the firewall isn't at fault and something else was..
@madamada Oh wait, I think I know what I've done wrong - Tayga is only converting IPv4 to IPv6 here, I still have to convert it back to IPv4 on with NAT64 the router / firewall... 🤦♂️ (because CLAT = NAT46)
It assumes you already have a local NAT64 in place which makes things a little easier to set up..
These steps are rather brief, assuming you already have Tayga installed..
CLAT on Host
Tayga configuration
> cat /etc/tayga.confRoutes
tun-device clat0
ipv4-addr 192.0.0.2
ipv6-addr 2001:db8:64:a::65
prefix 64:ff9b::/96
data-dir /var/db/tayga
wkpf-strict no
map 192.0.0.1 2001:db8:64:a::64
log drop reject
> cat /root/bin/routes-clat.shStart CLAT and run the script..
#!/bin/shifconfig tun11 create name clat0
ifconfig clat0 inet 192.0.0.1/29 192.0.0.1 up
ifconfig clat0 inet6 -ifdisabled
route -n add default -iface clat0
route -6n add 2001:db8:64:a::64/127 -iface clat0
service tayga startNAT64/PLAT
/root/bin/routes-clat.sh
sysctl net.inet6.ip6.forwarding=1
Tayga configuration
> cat /etc/tayga.confRoutes
tun-device nat64
ipv4-addr 10.64.64.1
prefix 64:ff9b::/96
wkpf-strict no
dynamic-pool 10.64.0.0/16
data-dir /var/db/tayga
log drop reject
> cat /root/bin/routes-nat64.shStart NAT64 and run the script..
#!/bin/sh
net4='10.64.0.0/16'
pref6='64:ff9b::/96'ifconfig tun11 create name nat64
ifconfig nat64 inet6 2001:db8:64:a::8200/128 up
route -n add -net $net4 -iface nat64
route -6n add -net $pref6 -iface nat64
service tayga startDNS64 - DNS64 with BIND9 or Unbound
/root/bin/routes-nat64.sh
sysctl net.inet.ip.forwarding=1
sysctl net.inet6.ip6.forwarding=1
BIND9
dns64 64:ff9b::/96 {
clients { localhost; localnets; trusted-nets; };
mapped { !10/8; !192.168/16; !172.16/12; any; };
exclude { 0::/3; 4000::/2; 8000::/1; 2001:db8::/32; };
recursive-only yes;
break-dnssec yes;
};
Unboundmodule-config: "respip dns64 validator iterator"This guide is based on my tests running on a FreeBSD VPS. The host acted as a CLAT client
dns64-prefix: 64:ff9b::/96
Update: Forgot to add the pf rules for NAT64..
ext_if="em0"
nat on $ext_if from 10.64.0.0/16 to any -> ($ext_if:0)
ProxLB v1.1.3 just got released!
ProxLB is a VM load-balancer for your Proxmox clusters also supporting affinity & anti-affinity rules.
GitHub: github.com/gyptazy/ProxLB
Version 1.1.3: https://github.com/gyptazy/ProxLB/releases/tag/v1.1.3
#Proxmox #vmware #virtualization #ProxLB #loadbalancing #enterprise #homelab #ipv6 #opensource #python #python3 #proxmoxve #VM #VPS #devops #coding
[root@ipv6-only ~/staging]# ifconfig epair0b ; ifconfig clat0 ; ping -c 2 9.9.9.9#freebsd #ipv6 #ipv6only
epair0b: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:a5:90:b5:02:0b
inet6 2400:8901:e002:7f70::111 prefixlen 64
inet6 fe80::a5:90ff:feb5:20b%epair0b prefixlen 64 scopeid 0x8
groups: epair
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
clat0: flags=1008051<UP,POINTOPOINT,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 1260
options=4080000<LINKSTATE,MEXTPG>
inet 192.0.0.1 --> 192.0.0.1 netmask 0xfffffff8
inet6 fe80::447:4771:9888:4033%clat0 prefixlen 64 scopeid 0xe
groups: tun
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Opened by PID 436
PING 9.9.9.9 (9.9.9.9): 56 data bytes
64 bytes from 9.9.9.9: icmp_seq=0 ttl=53 time=91.969 ms
64 bytes from 9.9.9.9: icmp_seq=1 ttl=53 time=91.193 ms--- 9.9.9.9 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 91.193/91.581/91.969/0.388 ms
@madamada I don’t have any personal experience, but just looking at the man page https://man.freebsd.org/cgi/man.cgi?query=ipfw&sektion=8&format=html, I wonder why setting up Tayga instead of using the integrated CLAT?
Regarding #DeltaChat, here are some useful links:
- Delta Chat
- Delta ChatMail
- Delta Chat Relays
I just tested ChatMail and it seems pretty good. It create's a random email address used for e2ee messaging between ChatMail users. You can choose one of the relays when creating a ChatMail address. It is also created as a separate profile in DeltaChat so as not to mixed with encrypted and non-encrypted profiles.
I hope this can make it's way to #debian with help of @andrew_shadura , please?
Very excited by the release of FreeBSD 14.3 ... looking forwards to higher-speed WiFi networking on both my desktop and laptop.
Question for the #freebsd folks here, though - do you have a make / model of PCI WiFi card you'd recommend for a recent desktop machine?
There are many, many manufacturers using Intel chipsets to choose from, but I'd love to hear from people who've used them with FreeBSD and have recommendations either for or against 🙏
Now I want to upgrade my existing jails to FreeBSD 14.3-RELEASE .. here are the steps taken..
freebsd-update -b /vm/host/ukyo --currently-running 14.2-RELEASE -r 14.3-RELEASE upgradeThe result was,
freebsd-update -b /vm/host/ukyo install
service jail restart ukyo
freebsd-update -b /vm/host/ukyo install
pkg -j ukyo bootstrap -f
pkg -j ukyo update
pkg -j ukyo upgrade -f
service jail restart ukyo
jexec ukyo sh -c "uname -rKU ; freebsd-version -ru"Good to go 🙂
14.3-RELEASE 1403000 1403000
14.3-RELEASE
14.3-RELEASE
I usually install my jails with bsdinstall(8).. My previous installs were using the distribution files for FreeBSD 14.2-RELEASE ..
But now I want to prep bsdinstall(8) to use the distribution files for FreeBSD 14.3-RELEASE .. Here's what I did..
cd /usrThen do the checksums on the files to see if they match the one's in the MANIFEST file
mv freebsd-dist freebsd-dist-14.2r
mkdir freebsd-dist
cd freebsd-distcat << _EOF > dists.txt
http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/14.3-RELEASE/MANIFEST
http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/14.3-RELEASE/ports.txz
http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/14.3-RELEASE/base.txz
http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/14.3-RELEASE/lib32.txz
_EOFfor x in `cat dists.txt` ; do curl -O "$x" ; done
grep base.txz MANIFESTNow when I want to install a new skeleton jail,
sha256 base.txz
...
mkdir /vm/jail/newHost
bsdinstall jail /vm/jail/newHost
So, *@discuss.systems ; still trying to wrap me head around this IPv6 thing, couldn't sleep last night thinking about it; even though in the past I have successfully setup an IPv6 network via Hurricane Electric Tunnel and receiving a badge at the time for having set it up to the point I could have my #OpenWrt router pinged on the other end of the tunnel.
Had no actual #IPv6 connection at that point, but now I believe I do.
Now I have muddled through a few tutorials on the subject and I am confused as ever.
I have at my disposal, the tools subnetcalc and the ipaddr library of python which is capable of calculating address ranges based on CIDR notation and for telling you if an address is a network address ranges, from what part of the world, or if an unicast single host address.
Half way through watching a video that recommends first watching another video with a painfully German guy who seems to really know his stuff and looks like my old coworker Brewbaker were he a bit taller, they must be relatives.
Allowing the Delegation of Global Address prefix seems to allow for sub-sub netting amongst the original address space, and if you want to prevent this it you disallow it like a land lord disallowing subletting in the lease agreement.
Also, my Xfinity connection seems to indicate that this prefix will change weekly. And if I want any of my servers to keep their static address they seem as though they will need to be readdressed manually every week, with a Global static address since the downstream prefix of their subnet would change with the weekly prefix change. And then I would have to change the firewall rules too!!!
Also it seems that somehow #arp has been replaced by #ICMPv6 and some totally confusing process called Neighbor Detection #ND in which routers and hosts advertise and solicitate.
Also, Site-Local addressing with a FEC0 range appears to have replaced the 172.0.0.0, 10.0.0.0 and 192.168.0.0 ranges but these have also been deprecated so they shouldn't be used.
And the I didn't-get-an-address, address, 169.0.0.0 has been replaced by FE80 addresses but they can oddly still be communicated with.
Seems like a mess to me, but learning something new tends to be like that.
Any tips for the blind group of men trying to describe the elephant to each other you can provide me would be appreciated.
- 2001:: = Global Unique Address
- fd00:: = Unique Local Address
- fe80:: = Link Local Address
Knowing those 3 is enough to get you going in most cases..
ARP is for IPv4 what NDP is for IPv6..
There is no broadcast address in IPv6..
IPv6 is a completely different protocol and addressing..looking at it from an IPv4 mindset just complicates things..
@madamada @leean00
Changing prefix and FW rules is easy to handle with #OpenWrt as FW4 allows for negative subnet masks. e.g. ::a1/-64
If you run services on a dynamic prefix delegation, you need to update your DNS records in a dynamic way, Depending what is at your disposal.
If you have a dyndns provider which allows only for a prefix update and updates all RRs is the easiest.
As @madamada said, forget you legacy protocol mind set. And start with a clean sheet.
However most of us live with dynamic prefixes, and this becomes a problem..luckily one way around this is to use ULA addressing internally, and map those addresses in DNS.
Then combine that with DynDNS or nsupdate if you are using your own domain name for the WAN side and configure port forwarding or a reverse proxy. You could also probably use NPTv6 to deal with dynamic prefix mapping but that's another beast all together..
@leean00
Negative network masks with the FW4 in #OpenWrt works the way that you allow whatever network prefix you have this rule will allow access to the host with the ::a1 host address.
DynDNS or nsupdate depending on your setup works. There are a few DynDNS providers that allow to update only the prefix and all AAAA RRs are updated automatically. Meaning that the router could run a script or ddnsclient and no need on the hosts.
My take on ULAs: use only where necessary.
@madamada Are adhock network connection possible?
@madamada When I was younger, I used to take my wiki on the train with me and I'd create a direct IPv4 connection between the laptop and the Raspberry Pi.
It required that you set the gateway and the netmask the same as to that of the other machine. No router involved, but a cross over cable.
Then I'd use the routing percentage thing to make sure I was equally connected between the ethernet to the pi and the wifi of the train (MTU, I think).
And I could access both the raspberry pi and the wifi internet.
@madamada okay thanks again, I'll have to try that out too
In IPv6, it's the same, for example:
pi
- fdaa::1/64
Laptop
- fdaa::2/64
On Laptop, after connecting cable, ping fdaa::1, if you get reply, then proceed to route -6n add default fdaa::1 and update /etc/resolv.conf to use fdaa::1 as default nameserver
@madamada One more ... sorry, if I want to redo the HE.net Cert, any idea what domains it will accept?
Already tried Gmail and protonmail