It’s been on my list to try and see how a client with just ipv6 actually works on the internet, since I know that all sites have not enabled ipv6 for eg: https://www.twitter.com. So while i could see that there were multiple ways to do this, the only one I could understand a bit was NAT64, or atleast it seemed like something I could try out after reading this link https://www.22decembre.eu/en/2016/05/28/openbsd-ipv6-router/.
Now my provider does not actually give me IPV6 connectivity. I figured maybe I could take a VM from a VPS provider, who also provides IPV6 connectivity and then use that to somehow route it back to my laptop at home and test it.
Below was what I thought would work.
IPV6 Internet ----
|--- VPS(VM) --- IPV6 Tunnel to VM on Laptop --- VM(laptop)
IPV4 Internet ----
Went ahead and purchased a $5 OpenBSD vm with https://vultr.com having both IPV4 and IPV6 ip’s provided to it. Couple of problems with this. Vultr ended up giving me a /64 IPV6 subnet. I could ping and browse the IPV6 internet, but I learned i could not really subnet this /64 further as the routing for this was not occuring. Could be that Vultr has a route only to the ip assigned to me and not the whole subnet. I asked vultr if they could provide a /48, but they said their policy was to only assign /64. I should have further probed on the /64 routing, but I left it at that.
Next step - I would require a /48 subnet, which I could then further subnet below to reach my Laptop VM and test.
https://tunnelbroker.net (Hurricane Electric) provides this for free!!.
EDIT: I could’ve created a tunnel direclty to my laptop, but it just did’nt come up, i assume due to it being
behind the wi-fi router.
Registered on their site, where they asked for my global IPV4 address and provided theirs to create a 6over4 tunnel.
they also provided configs for OpenBSD for this tunnel. while the source and destination for this tunnel are ipv4 the
actual ips on the endpoints of this tunnel are ipv6 eg. ::1 and ::2, for which they provide a /64. Additionally you can
check a box to have another /48 routed to this tunnel. Select that so that you are provided the /48 which you can store
somewhere.
New setup ended up looking like this.
Hurricane Electric --6over4 tunnel -- VultrVM -- IPV4 internet -- VM-1 (OpenBSD) --VirtualBox internal network -- VM-2 (Ubuntu)
The Ubuntu VM on my laptop would end up having pure ipv6 (subnetted from the /48 provide by HE), on which I would check and confirm both pure ipv6 connectivity and ipv4 connectivity.
Next step would be routed connectivity for the Ubuntu VM to Vultr VM. for this I setup a wireguard vpn from the Vultr VM to the OpenBSD VM on my laptop, then created another tunnel using the wg interface ips as the source and dest addresses and used another /64 subnetted from the /48 as the tunnel end point ip address. (Keep in mind, since the OpenBSD VM was natted the source ip was a private ip at its end, but the Vultr VM had my Internet ip as it destination.)
Connectivity now
HE --[60ver4]-- VultrVM --[WireGuard over Internet Tunnel]-- OpenBSD VM -- Ubuntu VM
Now an important part is DNS64, you could setup something link unbound, or you could use google’s DNS64 public server.
I decided to go with the google one, as I could always test unbound later. At the same time decided to setup DHCPv6 on the laptop OpenBSD VM using DNSMASQ.
Setup route forwarding on both the OpenBSD VM’s
sysctl -w net.inet.ip.forwarding=1
sysctl -w net.inet6.ip6.forwarding=1
if you want this to persist on your next reboot
echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf
echo "net.inet6.ip6.forwarding=1" >> /etc/sysctl.conf
at this point, I tested plain ipv6 internet and I could. So only the ipv4 part remains, Which surprisingly turned out to be very simple.
in /etc/pf.conf add
pass in log on <tunnel intf eg:gif1> inet6 from any to 64:ff9b::/96 af-to inet from <vultr ipv4 ip>
From Ubuntu VM open up firefox and test twitter.com .
Now while twitter worked, I was having issues browsing other ipv4 sites. After sometime I realised i would have to lower the mtu on the ubuntu VM. Once lowered to 1280, everything worked perfectly.