From a Tunnel Broker to Your Own /48

Audience: people running IPv6 at home through a tunnel broker, such as Hurricane Electric's tunnelbroker.net, who want addresses of their own. It builds on Announcing Your /48 from a VPS with BIRD, and uses the same documentation values: put your own in their place.

Last updated: October 2026

1. Why move

A tunnel broker's prefix belongs to the broker. It is part of the broker's own address space, so it is not yours to announce from another network, and it goes when the tunnel does. An isp6 /48 is assigned to you in the RIPE Database, with your certificate on the record, for as long as your membership runs. Its addresses stay the same whoever carries your traffic, and you announce it where you choose.

What stays the same: a tunnel from your home to a server that has native IPv6. What changes is whose server it is, and whose addresses travel down it.

2. The design

• A VPS announces your /48 over BGP, as in the previous guide.
• A WireGuard tunnel from the VPS to your home router carries part of it, a /56, home.
• The home router hands out a /64 per network from that /56, as it did with the broker's prefix.

Traffic for your home addresses reaches the VPS from the internet and goes down the tunnel. Traffic from home goes up the tunnel and out from the VPS.

A /56 holds 256 /64s, and a /48 holds 256 /56s. Planning Your isp6 Allocation covers carving it up for real.

3. The VPS end

Make a key pair on each end, as root, with umask 077 first so only root can read the private key:

umask 077
wg genkey | tee private.key | wg pubkey > public.key

Then on the VPS, in /etc/wireguard/wg0.conf:

[Interface]
Address = 2001:db8:1234:ffff::1/64
ListenPort = 51820
PrivateKey = <the VPS's private key>

[Peer]
# home
PublicKey = <home's public key>
AllowedIPs = 2001:db8:1234:ffff::2/128, 2001:db8:1234:100::/56

wg-quick turns AllowedIPs into routes, so the /56 is routed down the tunnel. That route is more specific than the /48 BIRD installs as unreachable, so traffic for home is forwarded and traffic for unused parts of the /48 is still refused.

The VPS now forwards packets, which Linux does not do by default:

echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee /etc/sysctl.d/90-forwarding.conf
sudo sysctl --system
sudo systemctl enable --now wg-quick@wg0

One catch: with forwarding on, Linux ignores router advertisements. If the VPS learns its own IPv6 default route from them, it loses it. Check with ip -6 route show default; if the route says proto ra, also set net.ipv6.conf.<uplink>.accept_ra = 2 for the interface it came in on, where <uplink> is its name (often eth0 or ens3).

Open UDP port 51820 in the VPS's firewall, and let forwarded traffic to and from wg0 through.

4. The home end

On the home router, /etc/wireguard/wg0.conf:

[Interface]
Address = 2001:db8:1234:ffff::2/64
PrivateKey = <home's private key>

[Peer]
# the VPS
PublicKey = <the VPS's public key>
Endpoint = 198.51.100.10:51820
AllowedIPs = ::/0
PersistentKeepalive = 25

Endpoint is the VPS's IPv4 address when home has no IPv6 of its own, which is usually why the tunnel broker was there. AllowedIPs = ::/0 makes the tunnel home's IPv6 default route, in place of the broker's. PersistentKeepalive keeps the tunnel open through home NAT and firewalls.

The router forwards between the tunnel and your networks, so it needs net.ipv6.conf.all.forwarding = 1 too. Routers built for the job (OpenWrt, OPNsense, pfSense) offer WireGuard in their interface settings, with the same settings as the file above.

5. Addresses at home

Give each home network a /64 from the /56 and advertise it, as you did with the broker's prefix. On a Linux router with radvd:

interface lan0 {
  AdvSendAdvert on;
  prefix 2001:db8:1234:100::/64 {
  };
};

Devices pick their own addresses from the advertised /64. Your firewall matters as much as it did with the broker: these addresses are public, and IPv6 has no NAT to stand in for a firewall. Keep a stateful rule set that drops what nobody at home asked for.

6. Cutting over

1. Announce the /48 from the VPS and check it is seen and RPKI-valid, as in the previous guide.
2. Bring up WireGuard at both ends; from home, ping 2001:db8:1234:ffff::1.
3. Move one network first. Reach a device on it from outside: a phone on mobile data, if the mobile network has IPv6, is the quickest test.
4. Move the rest, then update anything that names the old addresses: AAAA records, firewall rules, allow lists.
5. Delete the tunnel at the broker, and its configuration at home.
6. If you run your own DNS servers, delegate reverse DNS for the /48 to them from your isp6 dashboard.

7. What it costs you

• The VPS's traffic allowance. All of home's IPv6 traffic now passes through the VPS, in both directions. Check what the provider includes.
• Distance. Every packet takes a detour through the VPS, as it did through the broker. A VPS near home keeps the detour short.
• Packet size. WireGuard's overhead lowers the largest packet the tunnel carries. wg-quick sets a safe value for most connections; if large downloads stall, set MTU = 1380 in both [Interface] sections and try again.

8. Further reading

• WireGuard: Quick Start
• RFC 4861: Neighbor Discovery for IP version 6
• RFC 7084: Basic Requirements for IPv6 Customer Edge Routers
• IPv6 Security

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.