2

Setup

  • Desktop computer (MyComputer)
    • Mobo: ASRock
    • Distro: Arch Linux
  • Yunohost Server (Yunohost)
    • Mobo: Raspberry Pi 3
    • Distro: Debian
    • Main App: Yunohost/NextCloud
    • Domain registered at godaddy.com (mydomain.tld)
  • Yunohost Server (Xroklaus)
    • Mobo: Raspberry Pi 3
    • Distro: Debian
    • Main App: Yunohost/Duniter
    • Domain registered at FreeDNS.afraid.org (guilder-test.eu.org)
  • Modem
    • Fritz!Box 7581

My modem is automatically entering the wrong ipv6 address for at least two of my devices, resulting to DestinationNetworkUnreachable errors.

Tests from https://www.subnetonline.com

IPv6 Ping Output:

PING guilder-test.eu.org(2001:983:8610:1:2239:6fcb:6144:21d2 (2001:983:8610:1:2239:6fcb:6144:21d2)) 32 data bytes
From 2001:983:8610::1 (2001:983:8610::1) icmp_seq=1 Destination unreachable: Administratively prohibited
From 2001:983:8610::1 (2001:983:8610::1) icmp_seq=2 Destination unreachable: Administratively prohibited
From 2001:983:8610::1 (2001:983:8610::1) icmp_seq=3 Destination unreachable: Administratively prohibited
From 2001:983:8610::1 (2001:983:8610::1) icmp_seq=4 Destination unreachable: Administratively prohibited

--- guilder-test.eu.org ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3004ms

Modem settings enter image description here enter image description here

Desktop computer

enter image description here

My modem is automatically entering the wrong ipv6 address for my main computer. The address it enters is 73a:34a1:5d16:a67f when it should be 5766:a840:f358:5b00. I can manually edit it on the modem, but it will jump back to the old settings after some time.

IP lookup

[me@MyComputer ~]$ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:983:8610:1:5766:a840:f358:5b00/64 scope global dynamic noprefixroute 
       valid_lft 6571sec preferred_lft 3492sec
    inet6 fe80::90d9:53e6:a878:801c/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Network settings Network settings

/etc/NetworkManager/system-connections/MyWifi

[root@MyComputer ~]# cat /etc/NetworkManager/system-connections/MyWifi
[connection]
id=MyWifi
uuid=109dd5bb-9f07-465f-b2ef-0f7e40084345
type=wifi
permissions=user:me:;

[wifi]
mac-address=30:10:B3:0A:1C:85
mac-address-blacklist=
mode=infrastructure
ssid=MyWifi

[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=g4TK1DdyiPoOPo6tknNF4eInZthPEfyNYU7jJoRMXvuaea7pckpG43ahnBKZ5pJ

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

Server computers

The IPv6 interface ID that's picked up from one of the servers is correct, while the other enters either the link local scope or more surpisingly, the link local scope of the other server.

enter image description here

Thus the IPv6 interface ID of Yunohost resolves to either ::fb41:cbb3:2bec:e9c0 or the more suprising ::7664:c1e:6989:14b0 when it should be ::f3d5:e2a7:5d97:f45c.

Interfaces on YunoHost

admin@YunoHost:~ $ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:983:8610:1:f3d5:e2a7:5d97:f45c/64 scope global noprefixroute dynamic 
       valid_lft 5916sec preferred_lft 3396sec
    inet6 fe80::fb41:cbb3:2bec:e9c0/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 state DOWN qlen 1000
    inet6 fe80::3aa6:ea20:d318:e097/64 scope link tentative 
       valid_lft forever preferred_lft forever

Interfaces on Xroklaus

 admin@Xroklaus:~ $ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:983:8610:1:2239:6fcb:6144:21d2/64 scope global noprefixroute dynamic 
       valid_lft 5535sec preferred_lft 3461sec
    inet6 fe80::7664:c1e:6989:14b0/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 state DOWN qlen 1000
    inet6 fe80::5f05:b808:f4ad:b037/64 scope link tentative 
       valid_lft forever preferred_lft forever

/etc/network/interfaces

admin@Yunohost:~ $ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet manual

allow-hotplug wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

My other server has the same settings.

The modem also shows the two servers having a very odd connection, which does not reflect reality.

enter image description here

While Xroklaus looks normal

enter image description here

Yunohost on the other hand thinks it's connected to the modem via Xroklaus.

enter image description here

  • 1
    Is the modem working as a DHCPv6 server, or what do you mean by "my modem is entering the wrong ipv6 address"? There are two mechanisms by which hosts on a IPv6 LAN select their addresses: Stateless Address Autoconficuration (SLAAC) and DHCPv6. SLAAC works so that the router announces a prefix and hosts automatically select the lower part of the address, often based on the MAC address. DHCPv6 is more like DHCP(v4). A host can choose which mechanism it uses. SLAAC is the older of the two; maybe your hosts have chosen to use it instead of DHCPv6? resolvconf.conf has nothing to do with this. – Johan Myréen Dec 24 '17 at 7:02
  • Thank you for the information. I'm not familiar with networking, so I thought I had to look over there. Should I use DHCPv6 only? – Folatt Dec 24 '17 at 9:58
  • How do hosts automatically select the lower part of the address? I don't see MAC addresses being copied. – Folatt Dec 24 '17 at 10:03
  • 1
    The MAC address is mapped to an EUI-64 64-bit identifier by flipping the "universal/local" bit and inserting FFFE in the middle. See howdoesinternetwork.com/2013/… for the details. – Johan Myréen Dec 24 '17 at 10:16
  • 2
    The lower 64 bits of the address are typically randomly generated and non constant. If you want IPv6 machines to be publicly addressable, you should give them a fixed address, either by static configuration, or by using DHCP6 to assign a particular address to a given interface. While older machines may use a fixed EUI-64 identifier permanently, many will change their IPv6 machine identifier (low 64 bits) every X hours. Thus you may see addresses identified as "dynamic" or "dynamic deprecated" in your ip -6 a output. – user4556274 Dec 24 '17 at 10:43
1

The error message "Destination unreachable: Administratively prohibited" suggests there might be a firewall of some sort rejecting the IPv6 pings.

  • Yes. That firewall is apparently on the modem/router as I had been able to temporarily set the IPv6 interface IDs of all my computers on the modem to the correct interface hardware addresses. Thus I was able to ping6 my sites, until after a few minutes one by one, IPv6 Interface IDs were reset automatically. – Folatt Dec 26 '17 at 10:44
0

I had the exact same problem with a Raspberry Pi 3B+ behind a Fritz!Box 7581, so my solution may work for you as well.

  1. Edit /etc/dhcpcd.conf on the RPi and replace slaac private with slaac hwaddr.

  2. Even though it appears that IPv6 is fully enabled on the RPi, it may actually in the latest version of Raspbian Stretch be blocked in /etc/modprobe.d/ipv6.conf. Removing this file, or commenting its contents, removes that blockage.

  3. Make the FB7581 forget about the "old" RPi by shutting it down, waiting until it is listed under the idle connections, and then removing it.

  4. After (re)booting the RPi it should be possible under Permit Access to open it for Ping6, OpenVPN, etc. It worked for me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.