UniFi UDM Pro with DS-Lite at 1&1 behind a DrayTek Vigor 167

Contents

1. The setup
2. The symptom: IPV6CP timeout
3. Comparing with the FRITZ!Box
4. The fix: a fixed IPv6 interface ID
5. Keeping the fix
6. Bonus: lower your WireGuard MTU
7. Conclusion

The setup

For a long time my UniFi Dream Machine Pro sat behind a FRITZ!Box. That worked, but I wanted the UDM to handle the internet connection itself. So I bought a DrayTek Vigor 167 as a pure VDSL modem in bridge mode and connected it to the WAN port of the UDM.

My internet provider is 1&1 on a Telekom line. Like many newer 1&1 contracts, it uses DS-Lite over PPPoE. You get a native IPv6 connection with a /56 prefix, and IPv4 is tunneled through it to a gateway at 1&1 (the AFTR).

The UniFi side was configured the way you would expect:

• WAN1 → IPv4 Connection: IPv4 over IPv6, type DS-Lite over PPPoE, AFTR on auto
• IPv6: SLAAC with Prefix Delegation enabled
• VLAN: off, because the Vigor 167 already tags VLAN 7 itself

It did not work. With or without the H in front of the username. The FRITZ!Box on the same line, with the same credentials, connected instantly.

The symptom: IPV6CP timeout

The UDM writes its PPP log to /var/log/messages. So I connected via SSH and filtered for it:

grep ppp /var/log/messages | tail -50

The PPPoE discovery worked, and so did the authentication. The 1&1 router even sent its own IPv6 negotiation requests, which the UDM acknowledged. But the UDM’s own request was simply ignored:

sent [IPV6CP ConfReq id=0x3 <addr fe80::b0ed:c00a:17d5:6610>]
rcvd [IPV6CP ConfReq id=0x7 <addr fe80::fe1b:d1ff:feb2:209f>]
sent [IPV6CP ConfAck id=0x7 <addr fe80::fe1b:d1ff:feb2:209f>]
sent [IPV6CP ConfReq id=0x3 <addr fe80::b0ed:c00a:17d5:6610>]
...
IPV6CP: timeout sending Config-Requests
rcvd [LCP TermReq id=0x4]
LCP terminated by peer

No ConfAck, no ConfNak, nothing. After 60 seconds 1&1 terminated the session. And since DS-Lite needs IPv6 for everything, including the IPv4 tunnel, there was no internet at all.

Comparing with the FRITZ!Box

To see what the FRITZ!Box does differently, I recorded its PPPoE session with the built-in packet capture of the FRITZ!Box (http://fritz.box/html/capture.lua) and opened it in Wireshark. Two things stood out:

1. The FRITZ!Box proposes an IPv6 link-local address based on its MAC address (EUI-64). The UDM proposed a random interface ID: fe80::b0ed:c00a:17d5:6610.
2. The FRITZ!Box does not even try to negotiate IPv4 via IPCP. The UDM does.

The FRITZ!Box got its ConfAck within 20 ms. The cause turned out to be the random interface ID. UniFi generates the pppd config in /etc/ppp/peers/ppp0 with the line ipv6 ,, which tells pppd to pick a random ID. The 1&1 access router seems to silently drop those requests.

There is no setting for this in the UniFi interface. Cloning a different MAC address in the WAN settings does not help either, UniFi still writes ipv6 ,.

The fix: a fixed IPv6 interface ID

pppd reads /etc/ppp/options before the peer file. And an empty ipv6 , in the peer file does not overwrite an interface ID that was set earlier. UniFi does not touch /etc/ppp/options at all, so that is the place for the fix.

First calculate the EUI-64 interface ID from the MAC address of your WAN port. You can find it with ip link show eth8 on a UDM Pro. The recipe is simple:

1. Take the MAC, for example 74:ac:b9:12:34:56.
2. Flip the second lowest bit of the first byte: 74 becomes 76.
3. Insert ff:fe in the middle: 76ac:b9ff:fe12:3456.

Then add two lines to /etc/ppp/options via SSH and restart pppd:

cat >> /etc/ppp/options <<'EOF'
noip
ipv6 ::76ac:b9ff:fe12:3456,
EOF
killall pppd

noip disables the IPv4 negotiation, just like the FRITZ!Box does it. I am honestly not sure whether it is strictly necessary. The random interface ID was definitely the cause, but I left noip in since everything works with it.

A few seconds later the log looked like this:

sent [IPV6CP ConfReq id=0x2 <addr fe80::76ac:b9ff:fe12:3456>]
rcvd [IPV6CP ConfAck id=0x2 <addr fe80::76ac:b9ff:fe12:3456>]

Right after that the UDM got its /56 prefix, built the DS-Lite tunnel to aftr.online.versatel.de, and the internet was back.

Keeping the fix

In my tests UniFi did not overwrite /etc/ppp/options when I changed the WAN settings. The forced 24-hour reconnect at 1&1 also works fine with it. I am less sure about firmware updates, so I keep a copy in /data, which survives them:

mkdir -p /data/ppp-fix && cp /etc/ppp/options /data/ppp-fix/options

If the internet ever drops again with the same IPV6CP timeout, I check the file and restore it:

cp /data/ppp-fix/options /etc/ppp/options && killall pppd

Bonus: lower your WireGuard MTU

One more thing that bit me a few days later. DS-Lite over PPPoE leaves only about 1452 bytes for IPv4 packets. The default WireGuard MTU of 1420 results in packets that are too large, so they have to be fragmented. Behind the FRITZ!Box that was never a problem. Behind the UDM, small requests still worked, but TLS handshakes through my WireGuard VPN failed.

Setting MTU = 1380 in the [Interface] section of the WireGuard config fixed it. Normal TCP traffic is not affected, because the UDM clamps the MSS automatically.

Conclusion

The whole problem came down to a single line in a config file that the UniFi interface does not expose. It took me a packet capture on the FRITZ!Box to find it. If your UniFi gateway fails at the IPV6CP step with 1&1 DS-Lite, I hope this saves you a few hours. And if you are with a different provider that uses PPPoE with IPv6, a fixed interface ID is worth a try as well.