PF Best way to provide NAT64

patpro

patpro

Hello I would like to setup my gateway to provide dhcp6 and NAT64 to a part of my LAN.

I’m planning a migration from ISC DHCP to ISC Kea as soon as possible, it will provide dhcp6.

On the NAT64 front I’m not so sure:
- pf provides NAT64 on OpenBSD but it looks like this part has not been ported on FreeBSD
- many people write about Tayga but this software has not been updated for 12 years

What would be the best way to provide NAT64 in my context (pf) ?
 
Are you trying to use ipv6 on lan and only have ipv4 public ip ? If so, one of the options is to use free Hurricane Electric ipv6 tunnel, they let you setup a gre tunnel over ipv4 and you get a public ipv6 via the tunnel.
 
I have both IPv4 (/32) and IPv6 (/64) on the public interface of my gateway, but IPv6 is a recent addition and my LAN is currently 100% IPv4.
 
I see, in that case maybe instead of nat64 a better idea would be to use radvd on gw and let clients auto assign ipv6 (they may already be doing that). Unless ofcourse if you need to do static per mac assignments.
 
I was once trying to figure out the same and decided to do this rather than use nat64 as all of the projects i found seemed rather abandoned.
 
I like assigning a fixed IP per host on my wired LAN, on the WiFi part I don’t need it.
But I don’t see where it could replace NAT64. If a client on the LAN has only an IPv6 address and want to reach an IPv4-only server, I would still need something in between or is that something radvd would do?
 
patpro said:
If a client on the LAN has only an IPv6 address and want to reach an IPv4-only server, I would still need something in between or is that something radvd would do?
Click to expand...
For this purpose you would need nat64. Radvd only does ipv6 router advertisement.
Maybe someone else can chime in about nat64 on freeebsd
 
patpro said:
- many people write about Tayga but this software has not been updated for 12 years
Click to expand...
I'm using tayga for a few days now and it seems to work just fine ... I don't see why it would need any updates. It's doing stateless NAT64 on a tun device, that's a relatively simple and straight-forward job (so, I do stateful NAT44 again on the "v4-side" of tayga with pf).
 
zirias@ said:
(so, I do stateful NAT44 again on the "v4-side" of tayga with pf).
Click to expand...

I don’t understand that part (may be because I have not tested NAT64 yet…)
I’ve read your Mastodon thread about going full IPv6, that's what made me want to give it a try :) Do you plan on writing a full fledged article about your setup?
 
patpro said:
I don’t understand that part (may be because I have not tested NAT64 yet…)
Click to expand...
The "issue" with tayga is that it only implements "stateless NAT", this means without tracking any connection state. Therefore it needs to map exactly one IPv4 address to every (IPv6) source address it encounters. So, it won't work directly on your typical "consumer" plan giving you only a single public IPv4 address. That's why you have to add another stateful NAT mapping all the addresses tayga assigns to your IPv6 clients to your single public address, pretty much the same like you'd do for native internal IPv4.

patpro said:
Do you plan on writing a full fledged article about your setup?
Click to expand...
Actually didn't think about that. In the end, it's kind of trivial except for two things: net/tayga comes without an rc script, and the documentation about how to setup its tun(4) interface is Linux-specific. I'm currently using the following /usr/local/etc/rc.d/tayga (not tested on a reboot yet ...):
Bash: 
#!/bin/sh

# PROVIDE: tayga
# REQUIRE: DAEMON
# BEFORE:  netif
# KEYWORD: shutdown

. /etc/rc.subr

name=tayga
desc="NAT64 daemon"

rcvar=tayga_enable

load_rc_config ${name}

: ${tayga_interface:=nat64}

command="/usr/local/sbin/tayga"
pidfile=/var/run/tayga.pid
command_args="-p ${pidfile}"
stop_postcmd=tayga_poststop

tayga_poststop()
{
        /sbin/ifconfig ${tayga_interface} destroy
}

run_rc_command "$1"

and have the following in /etc/rc.conf for setup of the interface:
Code: 
ifconfig_nat64="inet 192.168.x.1 172.31.0.1 netmask 255.255.0.0"
ifconfig_nat64_ipv6="inet6 up"
static_routes="nat64"
route_nat64="-net 172.31.0.0/16 -iface nat64"
ipv6_static_routes="nat64"
ipv6_route_nat64="-net 2001:xxxx:xxxx:ffff::/96 -iface nat64"

where 192.168.x.1 is some local address (assigned to another interface) of my router/firewall machine and 2001:xxxx:xxxx:ffff::/96 is the NAT64-prefix I chose. As you can also see, I chose 172.31.0.0/16 for tayga to map IPv4 addresses to IPv6 source addresses.
 
Thank you very much, I think I have a better view now.
So basically the 6to4 route is:
6 source -> Tayga NAT64 into local dedicated subnet (1 to 1) -> "regular" NAT many-to-1 -> 4 destination

Is a DNS64 service compulsory in that setup?
 
patpro said:
Is a DNS64 service compulsory in that setup?
Click to expand...
Yes. The only other way to make NAT64 work is to have a CLAT, which provides some virtual IPv4 interface and statically translates that to IPv6, using your NAT64 prefix (so, basically, NAT46, if you want). A CLAT is the only way to deal with applications using old/deprecated v4-only APIs. It's definitely added complexity, you'll have your (local) IPv4 stack again. There's no OOTB solution on FreeBSD (or on Linux), there's a project called clatd implementing a CLAT based on tayga again (?), IIRC written in perl and it would probably need quite some changes to work on FreeBSD. Some operating systems (e.g. Android, iOS, newer Windows) contain a CLAT and fire it up automatically if NAT64 is detected, e.g. by router advertisements of a NAT64 prefix ... but that's not the case on FreeBSD.

DNS64 is quite easy with bind, all I did is add this to my config:
Code: 
        dns64 <nat64-prefix>::/96 {
                clients { <lan-prefix>::/64; };
                recursive-only yes;
                mapped { ! {
                        127.0.0.0/8;
                        10.0.0.0/8;
                        172.16.0.0/12;
                        192.168.0.0/16;
                }; any; };
        };
 
My local resolver is a Pihole but it forwards to my bind so I can probably do something to handle DNS64.
Thanks!
 
Some good news if you want to try NAT64 + CLAT (464xlat) on FreeBSD. I have gotten this to work already with the latest FreeBSD 14.3-R. But I'm not using net/tayga, I'm using Tayga that's actively being maintained by apalrd from Github.

Here's how it looks like:
Code: 
vtnet0: flags=1028943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC,LOWER_UP> metric 0 mtu 1500
    options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
    ether 08:00:27:ac:b9:8e
    inet6 fe80::a00:27ff:feac:b98e%vtnet0 prefixlen 64 scopeid 0x1
    inet6 fd00:babe::1337 prefixlen 64
    inet6 304:7a70:ab1e:401d:a00:27ff:feac:b98e prefixlen 64 autoconf pltime 600 vltime 600
    inet6 fd00:babe::a00:27ff:feac:b98e prefixlen 64 autoconf pltime 600 vltime 600
    media: Ethernet autoselect (10Gbase-T <full-duplex>)
    status: active
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
clat0: flags=1008051<UP,POINTOPOINT,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 1500
    options=4080000<LINKSTATE,MEXTPG>
    inet 192.0.0.1 --> 192.0.0.1 netmask 0xfffffff8
    inet6 fe80::a00:27ff:feac:b98e%clat0 prefixlen 64 scopeid 0x3
    groups: tun
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    Opened by PID 12201
madamada@bsdvm:~/ > ping -c2 -n 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=52 time=12.542 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=52 time=19.216 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.542/15.879/19.216/3.337 ms
madamada@bsdvm:~/ > curl -kI https://8.8.8.8/       
HTTP/2 302
x-content-type-options: nosniff
location: https://dns.google/
date: Fri, 11 Jul 2025 16:27:59 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
Code: 
madamada@bsdvm:~/ > netstat -rn4
Routing tables

Internet:
Destination        Gateway            Flags         Netif Expire
default            link#3             US            clat0
127.0.0.1          link#2             UH              lo0
192.0.0.1          link#3             UH            clat0
 
You must log in or register to reply here.
Back
Top