how do i convince Alpine Linux that it doesn't have IPv4 connectivity? when i run e.g. "ping bbc.co.uk", it picks the IPv4 address first, even though it doesn't have a default route.

i can't disable IPv4 because i need it for Wireguard.

i can't use /etc/gai.conf because musl libc doesn't support that.

this makes e.g. apk very slow because it waits for IPv4 to time out before it tries IPv6. i don't understand why it doesn't immediately get "no route to host" over IPv4...

any ideas?

#ipv6 #alpinelinux

@lw What does "ip -4 route" look like? There might be a default route that it's trying to connect through, one which dead-ends but it won't know that until it tries. For WG, if you remove the default route and replace it with a static route for precisely the WG endpoint, I think that should result in all Legacy IP traffic being unroutable except for WG.

@litchralee_v6

hyacinth:~# ip -4 route
23.155.224.0/24 dev eth0 proto kernel scope link src 23.155.224.95
176.126.243.164 via 23.155.224.1 dev eth0
hyacinth:~#

that /32 route is the Wireguard endpoint, no default route.

@lw Firstly, I want to apologize for missing the part in your original post where you already said there was no default route. I now see how strange the situation is.

It's perplexing as to what would be holding up the v4 connection. Is tcpdump or Wireshark available to examine the traffic? The primary DNS server is on v6?

@litchralee_v6 okay so, bizarrely, the packets are going over the Wireguard interface.

hyacinth# ping bbc.co.uk
PING bbc.co.uk (151.101.192.81): 56 data bytes

---

hyacinth:/etc# tcpdump -ni rose dst host 151.101.192.81
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on rose, link-type RAW (Raw IP), snapshot length 262144 bytes
13:35:52.189219 IP 23.155.224.95 > 151.101.192.81: ICMP echo request, id 8050, seq 57, length 64
13:35:53.189802 IP 23.155.224.95 > 151.101.192.81: ICMP echo request, id 8050, seq 58, length 64
13:35:54.189848 IP 23.155.224.95 > 151.101.192.81: ICMP echo request, id 8050, seq 59, length 64

but there's no route, so this shouldn't be happening. perhaps wg-quick is doing some "helpful magic" here?

(i usually use plain wg, but that seems to be a bit of a pain on Linux...)

@lw I think, but I'm not certain, this might be due to how WG attaches itself to the iptables/nftables chain, stealing packets before they get to the routing decision.

Perhaps "iptables -vL" will show something along those lines? It's been a while since I've dealt with iptables, and I now mostly prefer to do WG in a separate namespace so that my application containers don't have to be dual-stack.

@litchralee_v6 yeah, i think it must be something like that. for now i'm going to leave it with my hacky OUTPUT REJECT rule and come back to this later :D thanks for the help!