ewpratten.com/content/blog/2022-06-08-bell-ipv6.md

layout	title	description	date	tags	draft	extra
page	How I hacked full IPv6 support into a Bell residential network	Circumventing nearly everything my ISP has set up in the name of public IPv6 addresses for my friends	2022-06-08	networking	true	auto_center_images excerpt true I used multiple layers of IP encapsulation to evade an upstream firewall in the name of IPv6.

At this point, I feel like I should actually just start my own ISP.

I recently moved into a new place, and with that process came the exciting adventure of setting up a strong enough internet link to support a bunch of students who can collectively pull scary amounts of data through my networking gear concurrently.

After a bit of debate, we settled on a 1.5Gbps fiber connection provided by Bell Canada for the backbone of the new home network. Part of the reason for this is the fact that Bell has a fiber termination directly in my garage, making my hobby network engineering shenanigans even more fun (10GBps SFP+ connections, anyone?).

Bell: good for the average user

I'm not the average user.

Bell's service is exceptional for the average user, and they appear to have pretty great customer support, but when you want to push beyond the expected use cases of their services they only put up barriers, and nothing is documented!

The goal of this process was to bring IPv6 support into my home network.

Bell, for no particular reason doesn't support IPv6 in their residential networks, so this immediately went from "oh, it should be a quick config change" to a week spent fighting with a modem.

Bringing IPv6 to an IPv4-only network

This is not an uncommon situation, and I've done it before in many previous networks. Conveniently, as a part of the IPv6 transition plan, tools like 6in4 and Teredo exist.

Both tunneling protocols use IP Encapsulation to transport IPv6 traffic over IPv4 network segments. A brief comparison of these two of many protocols is as follows:

• 6in4
  • Uses IP Protocol 41
  • Prepends an IPv4 header to an IPv6 packet
  • 20 byte overhead (MTU 1480)
• Teredo
  • Encapsulates IPv6 traffic in IPv4 UDP packets
  • Relies on IPv6 compatible servers elsewhere to unwrap the packets and re-send them as native IPv6 traffic on the public internet
  • Used by Xbox consoles for multiplayer networking

I chose 6in4, mostly because I felt like it 😆. I'm sure Teredo would have brought me on an equally interesting journey, and maybe I'll see what its all about some other day.

Below is a diagram of a typical 6in4 packet:

Tunnel brokerage

When creating a 6in4 tunnel, you must have a server on the other end of the tunnel with:

• IPv6 connectivity
• A large IP block to allocate to the client(s)
• A strong backbone network connection

For this, I decided to once again go with my trusty first pick for all things global networking: Hurricane Electric (totally not because they gave me a free shirt or anything). One of Hurricane Electric's products is Tunnel Broker, a free tunnel brokerage service with endpoints all over the world.

Before I continue further down the path of explaining the tunnel setup, I must point out the next issue I ran into with Bell's internet service. ICMP data is blocked at the neighborhood and/or city level. This is an issue because all tunnel brokers require the ability to ping their clients to ensure tunnel health. No ping, no IPv6 for me.

Bypassing the Bell router

Now, we enter the territory of undocumented Bell router features.

The Home Hub 4000 is Bell's all-in-one modem, router, switch, access point, and smart home hub. From my point of view, it kinda sucks at all of those things, but luckily, it can be bypassed.

I have my own much superior Unifi Dream Machine PRO which is doing the heavy lifting of this home network. With a bit of configuration tweaking clearly designed for a small handful of Bell technicians, the UDM-PRO can be configured to act in place of the HH4K mentioned above.

The rest of these instructions will be UDM-PRO specific, but should be fairly easily adaptable to other routers.

Authenticating a non-Bell router

Personal networking gear can be used in place of Bell gear via a mechanism called Point-to-Point Protocol over Ethernet (PPPoE). PPPoE is an encapsulation method for allowing two routers to talk directly to each other over an ethernet cable without a network in-between.

To set up a PPPoE session with an HH4K router, you first need what other network engineers have come to call your "B1 Username". To view it, log in here, click on your internet service, and it'll be marked as your "User ID".

You'll also need your PPPoE session password. Apparently, Bell installation technicians can give it to you at the time of install, but I forgot to ask. So in that case, it can be (re)set to something you know by heading here, clicking your internet service in the side bar, and resetting your "Internet access password". (NOTE: This reset function doesn't like Firefox)

With your PPPoE credentials handy, you can log in to your own UDM, head to your WAN settings, then:

1. Set Advanced to Manual to gain access to PPPoE settings
2. Ensure the VLAN ID is not set (some guides say to set this as 35, but thats for if you want to plug the Bell fiber straight into the UDM, and that setup has bad reliability issues)
3. Set IPv4 Connection to PPPoE
4. Enter your credentials
5. Ensure IPv6 Connection is disabled (yes, I know the goal of this process. Trust me.)

Activating the hidden bridge mode in the modem

The HH4K "does not" support bridge mode. Unless you turn it on that is. The guides online were very misleading about this, but I eventually found the answer by piecing together a bunch of reddit comments.

To enable bridge mode on the Home Hub 4000, plug a computer into its ethernet switch, then:

• Disable DHCP
• Disable WPS
• Finally, disable WIFI

Assuming you correctly set up PPPoE using the instructions above, your router should disappear from the devices list, and only your computer should remain as a connected device. Check back in the Unifi Controller, and the UDM-PRO will have your real Bell WAN address. This may take up to 5 minutes.

Tunnel server setup

At this point, everything on the local network side is ready for a SIT tunnel, and we need to set up the server side.

Even though the HH4K is bypassed, Bell will still not allow pings through to the UDM-PRO, so Tunnel Broker will not quite work yet.

Router setup

SELinux: OFF Firewall: OFF

/etc/sysctl.d/wireguard.conf

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.he-ipv6.proxy_ndp=1

badger wg config:

[Interface]
Address = 2001:dead:beef:2::1/64
PrivateKey = <private-key>
ListenPort = 51820
PostUp = ip6tables -A FORWARD -i he-ipv6 -o %i -j ACCEPT; ip6tables -A FORWARD -i %i -o he-ipv6 -j ACCEPT;
PostDown = ip6tables -D FORWARD -i he-ipv6 -o %i -j ACCEPT; ip6tables -D FORWARD -i %i -o he-ipv6 -j ACCEPT;

[Peer]
PublicKey = <public-key>
AllowedIPs = 2001:dead:beef:2::0/64
Endpoint = <udm-pro-wan-address>:51821
PersistentKeepalive = 25

udm-pro wg config:

[Interface]
Address = 2001:dead:beef:2::1/64 #2001:470:1d:329::1/64 
PrivateKey = <private-key>
ListenPort = 51821
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE; ip route del 2001:dead:beef:2::/64 dev %i; ip route add 2001:dead:beef:2::/64 dev %i metric 512
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o bro -j MASQUERADE


[Peer]
Endpoint = <badger-ip-address>:51820
PublicKey = <public-key>
AllowedIps = 2000::/3
PersistentKeepalive = 25