Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 not working with Hetzner Cloud #29

Closed
quexten opened this issue Aug 8, 2019 · 9 comments

Comments

@quexten
Copy link

commented Aug 8, 2019

Hi,

first of all, thanks for this script, it's very helpful when setting up a Wireguard server.
I tried running this script on a Hetzner VPS using a Debian 10 and Ubuntu 18.04.
Hetzer assigns you an ipv4 address and a public ipv6 /64 prefix.
Running this script, i am able to connect with a client, ping the servers private v4 and v6.
My public v4 traffic from the client also gets successfully routed through the server.
My public v6 traffic from the client gets routed to the server, but then vanishes.
To debug this i pinging a public v6 address from the server (ipv6.google.com),
which was unsuccessful. So i tried turning off Wireguard, which made the pings go through again. When disabling the servers private ipv6 address by removing it, and then enabling Wireguard, i have successful public ipv6 access (both on the server, and the client routed through the server). However it would be better to have private v6 access too.
I'm not quite sure how to debug this as i'm not very experienced with linux networking.

I tried this on Digitalocean, where you have a single ipv6 address, and there the script works as expected, so my guess is the ipv6 address prefix.

Thanks!

@angristan angristan added the bug label Aug 8, 2019

@angristan angristan changed the title Public Ipv6 Access Stops Working When Server Has Public /64 Prefix IPv6 not working with Hetzner Aug 8, 2019

@angristan angristan changed the title IPv6 not working with Hetzner IPv6 not working with Hetzner Cloud Aug 8, 2019

@angristan

This comment has been minimized.

Copy link
Owner

commented Aug 8, 2019

I already noticed it on angristan/openvpn-install#295.

Hetzner set the preferred_lft of the IPv6 block as 0 second, causing it to be deprecated right when you add another inet6.

I describe the temporary and permanent fix in the issue.

I was able to reproduce it again:

root@debian-2gb-nbg1-1:~# ip -6 -c a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    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 2a01:4f8:c2c:8ebe::1/64 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fe80::9400:ff:fe2d:532c/64 scope link
       valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000
    inet6 fd42:42:42::1/64 scope global
       valid_lft forever preferred_lft forever
root@debian-2gb-nbg1-1:~# ip -6 addr change 2a01:4f8:c2c:8ebe::1/64 dev eth0 preferred_lft forever
root@debian-2gb-nbg1-1:~# ip -6 -c a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    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 2a01:4f8:c2c:8ebe::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::9400:ff:fe2d:532c/64 scope link
       valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000
    inet6 fd42:42:42::1/64 scope global
       valid_lft forever preferred_lft forever

After changing the preferred_lft to forever, the inet6 is not deprecated and the server and clients regain IPv6 connectivity.

@angristan angristan added help wanted info and removed bug labels Aug 8, 2019

@quexten

This comment has been minimized.

Copy link
Author

commented Aug 9, 2019

Yeah this fixes it for me aswell. Would it make sense to add an automated fix for this to the installer?

@angristan

This comment has been minimized.

Copy link
Owner

commented Aug 9, 2019

I'm not sure if it's worth bloating the script of this.

@angristan

This comment has been minimized.

Copy link
Owner

commented Aug 9, 2019

Actually just issuing ip -6 addr change <ipv6>/64 dev eth0 works

@angristan

This comment has been minimized.

Copy link
Owner

commented Aug 9, 2019

So running a ping6 + tcpdump, here is what I found:

When wg is up the source is wg0's IP (which is not correct - this is the issue)

17:27:22.851776 IP6 (flowlabel 0x1e23e, hlim 64, next-header ICMPv6 (58) payload length: 64) fd42:42:42::1 > fra16s25-in-x0e.1e100.net: [icmp6 sum ok] ICMP6, echo request, seq 17

When wg is down (OR when wg is up + ip -6 addr...), the source IP is correct:

17:27:23.855798 IP6 (flowlabel 0xbdb1d, hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:4f8:c010:1031::1 > fra16s25-in-x0e.1e100.net: [icmp6 sum ok] ICMP6, echo request, seq 18
17:27:23.860748 IP6 (flowlabel 0xbdb1d, hlim 54, next-header ICMPv6 (58) payload length: 64) fra16s25-in-x0e.1e100.net > 2a01:4f8:c010:1031::1: [icmp6 sum ok] ICMP6, echo reply, seq 18
@angristan

This comment has been minimized.

Copy link
Owner

commented Aug 9, 2019

See src here:

root@debian-2gb-fsn1-1:~# ip route get 2a00:1450:4001:820::200e
2a00:1450:4001:820::200e from :: via fe80::1 dev eth0 src fd42:42:42::1 metric 1024 pref medium

Now I have to figure out why it's using this one.

The route don't seem bad:

root@debian-2gb-fsn1-1:~# ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2a01:4f8:c010:1031::/64 dev eth0 proto kernel metric 256 pref medium
fd42:42:42::/64 dev wg0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 onlink pref medium
@angristan

This comment has been minimized.

Copy link
Owner

commented Aug 9, 2019

From: http://www.davidc.net/networking/ipv6-source-address-selection-linux

non-deprecated address(es) will be favored

So I think this really is the issue here, by default a clean Hetzner VM will have a single deprecated inet6, so all traffic will still go trough it, but once you add another inet6, the new one will be favored.

@angristan

This comment has been minimized.

Copy link
Owner

commented Aug 9, 2019

In the end, the issue was that the inet6 was assigned to the eth0:0 virtual interface: https://serverfault.com/questions/978664/how-is-preferred-lft-set-by-default-for-an-ipv6/

@angristan angristan removed the help wanted label Aug 12, 2019

@angristan

This comment has been minimized.

@angristan angristan closed this Aug 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.