How could I eliminate immediate IPv4? (NAT/proxy it through IPv6)

IsaacFL

@skilledinept
You could set up a NAT64 gateway device pretty easy. I ran one for the past year based on Jool and was easy to get working with pfsense.

What I found is that some IOT type devices just only work with ipv4. In my case I had a ring doorbell and Wemo switches that don’t even have ipv6.

On desktops NAT64 pretty much works except Steam on Windows. Steam requires a working ipv4.

The way I set it up was to virtualize my pfsense and then created another VM for the NAT64 gateway.
It

senseivita

Thanks for answering.

Yeah, my APs (Ubiquiti Networks' UniFi) are IPv4-only for some reason but if you SSH into them there's the ip command available so I could set and emergency IPv6 address for recovery…the bad thing is that I'm pretty sure RADIUS would stop working bc I don't have the slightest idea how to set it up without the controller you use to manage them.

But if I start with a few VLANs only I may have a shot and with the tip you just gave me I at least know it's doable. ️ …and I'm already running virtual!--I can just clone more VMs from the master template. 2x-thanks!

I've a question though, how did you manage DNS? Because I assume there it should be translated into IPv6 too otherwise since clients don't have IPv4, they won't have a working route to an IPv4 DNS resolution. Will they?

senseivita

Nevermind! I just found out about DNS64 servers!

IsaacFL

@skilledinept
if you have an ipv4 only local device that you want to access via NAT64 then you can create a host override in unbound with 64:ff9b::

For instance I have an Wireless AP that is only accessible via ipv4 at 10.23.30.10.
I create a host override:
wap.mydomain.com 64:ff9b::10.23.30.10

It will then get routed through the NAT64 as long as you have appropriate fw rules.

IsaacFL

@skilledinept said in How could I eliminate immediate IPv4? (NAT/proxy it through IPv6):

Nevermind! I just found out about DNS64 servers!

pfsense/unbound supports DNS64.

add following to dns resolver custom options

server:
module-config: "dns64 validator iterator"
dns64-prefix: 64:ff9b::/96

But only do this after your NAT64 is working.

senseivita

Yeah, got it.

I'd prefer if it was more transparent/native to the client (i.e; without special addressing) but this is just for fun and learning something new so it'll do.

Thanks again, this'll keep me busy for a while, I hope. :)

IsaacFL

@skilledinept actually the client won't even notice it as long as you have DNS64/NAT64 working and you can still run dual stack for the cases that don't work.

I may go ahead post my little step by step to set it up.

JKnott

@skilledinept said in How could I eliminate immediate IPv4? (NAT/proxy it through IPv6):

Yeah, my APs (Ubiquiti Networks' UniFi) are IPv4-only

????

While the management interface may be IPv4 only, any AP that doesn't pass every protocol is defective. I have an Asus portable AP, which I bought about 13 years ago, which has no problem passing IPv6.

I've a question though, how did you manage DNS? Because I assume there it should be translated into IPv6 too otherwise since clients don't have IPv4, they won't have a working route to an IPv4 DNS resolution. Will they?

It makes no difference whether DNS is carried over IPv4 or IPv6.

johnpoz

@skilledinept said in How could I eliminate immediate IPv4? (NAT/proxy it through IPv6):

Yeah, my APs (Ubiquiti Networks' UniFi) are IPv4-only

I'm with @JKnott here - ????

Not sure where you would of gotten that idea at all..

Are you blocking multicast on your wifi network - this can break IPv6 for sure..

But here... I can ping an AP ipv6 link local address

root@NewUC:/tmp# ping -6 fe80::822a:a8ff:fe13:4f07%ens3
PING fe80::822a:a8ff:fe13:4f07%ens3(fe80::822a:a8ff:fe13:4f07%ens3) 56 data bytes
64 bytes from fe80::822a:a8ff:fe13:4f07%ens3: icmp_seq=1 ttl=64 time=1.30 ms
64 bytes from fe80::822a:a8ff:fe13:4f07%ens3: icmp_seq=2 ttl=64 time=0.494 ms
64 bytes from fe80::822a:a8ff:fe13:4f07%ens3: icmp_seq=3 ttl=64 time=0.501 ms

You do understand when you use link-local that you have to call out the interface right.. See the "%ens3" in my ping.. this tells the box your doing the command on which interface to use.

And you can set an IPv6 address on them - you prob won't be able to ssh into if you set that because it wouldn't be listening on the port without a restart, and you would loose the address most likely.. I setup an IPv6 on them and could ping it..

But the management IP doesn't have anything to do with the AP passing IPv6 traffic..

senseivita

@JKnott Yeah, I meant for management and because of you set a RADIUS server on the Controller software for the APs to forward their stuff. Then you also set the APs' IP address or the whole subnet on the RADIUS server, but if the AP doesn't have an IP address (because officially IPv6 isn't supported) then it becomes an L2-only device, what they're actually supposed to be, right? Being an L2 device though it has no way of contacting (through IP) the RADIUS server to forward the traffic. There's always always-on IKEv2 or ZeroTier though. – I've static routes to an OPNsense gateway for ZeroTier, it doesn't even NAT, it's pure unfiltered routing like grandma used to splice. #applysepia

IPv6 works fine, @johnpoz multicast works "fine" too, well y'know…for multicast. I've a similar block BTW! It's from HE, right? I've memorized the /48 I'm borrowing, it makes it super easy to know every address on any subnet if you zero them out. It's my v4 I can't learn, it's one of those too matchy, sort of palindrome-y, that you think it's going to be easier when you look at it but isn't.

Thanks for the advise, guys!

🧩

JKnott

@skilledinept

Forget about the management interface and radius for a moment. The purpose of an AP is to provide a layer 2 connection between devices. That's it. So, it should pass IPv4 & IPv6 equally well. I get the impression your radius server is IPv4 only. Is that a problem? Can the clients only connect via IPv6? These days, dual stack is quite common and normally IPv6 is preferred, with fallback to IPv4.