Linux not preferring ipv6 on dhcpv6 network

3

On my home network, I'm using a (Raspbian) Raspberry Pi as a wifi router with hostapd, isc-dhcp-server, radvd, pihole, and dnscrypt-proxy installed. I do not use dhcpcd, I use dhclient. As I only get one ipv4 address and one ipv6 address from my ISP, I have both dhcp and dhcpv6 servers and NAT set up. When connecting to the wifi network, everything works perfectly and I can use both ipv4 and ipv6 to connect to the internet. However, if I ping a host, the ipv4 address is used:

$ ping google.com
PING google.com (216.58.212.174) 56(84) bytes of data.
64 bytes from ams15s22-in-f174.1e100.net (216.58.212.174): icmp_seq=1 ttl=55 time=16.1 ms
64 bytes from ams15s22-in-f174.1e100.net (216.58.212.174): icmp_seq=2 ttl=55 time=16.3 ms
64 bytes from ams15s22-in-f174.1e100.net (216.58.212.174): icmp_seq=3 ttl=55 time=16.5 ms

I want to use ipv6 by default. Without the Raspberry Pi, ping uses the ipv6 address:

$ ping google.com
PING google.com(ams15s22-in-x0e.1e100.net (2a00:1450:400e:801::200e)) 56 data bytes
64 bytes from ams15s22-in-x0e.1e100.net (2a00:1450:400e:801::200e): icmp_seq=1 ttl=56 time=103 ms
64 bytes from ams15s22-in-x0e.1e100.net (2a00:1450:400e:801::200e): icmp_seq=2 ttl=56 time=18.5 ms
64 bytes from ams15s22-in-x0e.1e100.net (2a00:1450:400e:801::200e): icmp_seq=3 ttl=56 time=16.8 ms

This behaviour extends to browsers, curl, wget...

I've tested the network both with and without the Pihole DNS server, there's no difference in behaviour, so I don't think that would be the cause.


My local setup:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 30:65:ec:b8:45:66 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b2:a5:95:7c:58:a0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.161/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 83213sec preferred_lft 83213sec
    inet6 fd97:367f:e5b4:8c28:17e3:4ca9:b7b8:3150/64 scope global dynamic noprefixroute 
       valid_lft 86275sec preferred_lft 14275sec
    inet6 fe80::755f:ab92:41fe:9872/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

/etc/gai.conf is empty.


My Raspberry Pi setup:

/etc/dhcp/dhcpd.conf:

default-lease-time 86400;
authoritative;
subnet 192.168.0.0 netmask 255.255.255.0 {
    range 192.168.0.2 192.168.0.254;
    option routers 192.168.0.1;
    option domain-name-servers 192.168.0.1;
}

/etc/dhcp/dhcpd6.conf:

default-lease-time 2592000;
authoritative;
subnet6 fd97:367f:e5b4:8c28::/64 {
    range6 fd97:367f:e5b4:8c28:0000:0000:0000:2 fd97:367f:e5b4:8c28:ffff:ffff:ffff:fffe;
    option dhcp6.name-servers fd97:367f:e5b4:8c28:0000:0000:0000:1;
}

/etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
iface eth0 inet6 auto
privext 2

auto wlan0
allow-hotplug wlan0
iface wlan0 inet static
    address 192.168.0.1
    netmask 255.255.255.0
    up iptables-restore < /etc/iptables.ipv4.nat
iface wlan0 inet6 static
    address fd97:367f:e5b4:8c28:0000:0000:0000:1
    netmask 64
    dad-attempts 0
    up ip6tables-restore < /etc/iptables.ipv6.nat

/etc/radvd.conf:

interface wlan0 {
    AdvSendAdvert on;
    prefix fd97:367f:e5b4:8c28::/64 {};
};

/etc/iptables.ipv4.nat:

# Generated by iptables-save v1.6.0 on Fri Feb  8 13:46:33 2019
*filter
:INPUT ACCEPT [74:5800]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [96:7812]
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
COMMIT
# Completed on Fri Feb  8 13:46:33 2019
# Generated by iptables-save v1.6.0 on Fri Feb  8 13:46:33 2019
*nat
:PREROUTING ACCEPT [1844:56256]
:INPUT ACCEPT [4:513]
:OUTPUT ACCEPT [6:492]
:POSTROUTING ACCEPT [1:48]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Feb  8 13:46:33 2019

/etc/iptables.ipv6.nat:

# Generated by ip6tables-save v1.6.0 on Fri Feb  8 13:59:43 2019
*filter
:INPUT ACCEPT [105:9056]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [63:7044]
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
COMMIT
# Completed on Fri Feb  8 13:59:43 2019
# Generated by ip6tables-save v1.6.0 on Fri Feb  8 13:59:43 2019
*nat
:PREROUTING ACCEPT [7:584]
:INPUT ACCEPT [1:104]
:OUTPUT ACCEPT [1:140]
:POSTROUTING ACCEPT [1:140]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Feb  8 13:59:43 2019

net.ipv4.ip_forward and net.ipv6.conf.all.forwarding are set to 1 in /etc/sysctl.conf. dhcpcd is disabled and stopped.

vw5E4opn

Posted 2019-02-08T17:47:34.637

Reputation: 31

I don't see any global IPv6 addresses in your configuration. Where are you expecting them to come from? – Michael Hampton – 2019-02-08T23:37:05.010

The Raspberry Pi gets a single global ipv6 address on the ethernet interface, eth0. (See /etc/network/interfaces) NAT is used between eth0 and wlan0 both on ipv4 and ipv6 level. I'm sorry if this wasn't clear. – vw5E4opn – 2019-02-09T09:09:40.330

The eth0 interface isn't even shown in your question at all. Nor is any interface from your Raspberry Pi, apparently. – Michael Hampton – 2019-02-09T16:58:49.017

What do you mean? I posted the contents of /etc/network/interfaces? It contains the lo, eth0, and wlan0 interfaces? – vw5E4opn – 2019-02-09T17:05:26.970

You did not post the output of ip a! – Michael Hampton – 2019-02-09T17:06:26.983

Answers

0

So after googling some more about NAT66, I found this blog post: https://mcilloni.ovh/2018/01/20/oh-god-why-NAT66/

Indeed, the writer had the same problem as me, and the solution is to edit /etc/gai.conf in order to remove the label of the fc00::/7 subnet (i.e. handled the same as global IPv6 addresses). Unfortunately the issue is a combination of network and client interaction, so every client has to do the same configuration change.

vw5E4opn

Posted 2019-02-08T17:47:34.637

Reputation: 31