VPN IPv6 connection

[klmhsb42]

Could you tell me if VPN app should work with IPv6? I can only access from my private network with IPv4 and can only get IPv4 tunnel through my DSlite even if I choose "combined IPv4/IPv6 Tunnel" in my openVPN andorid app. I can not access from extern IPv6 network. To open port 1194 doesn't help, which I don't need if I understand correctly. openVPN app logs say that the app is trying to connect with [IPv6]:1194 via UDP and [subdomain.syncloud.it]:1194 (IPv6) via UDPv6 which both are failing.

[cyberb]

the dhcpcd client with the option ia_pd https://manpages.debian.org/testing/dhcpcd5/dhcpcd.conf.5.en.html#ia_pd

I like this approach, do you think it will not break the network if dhcpv6-pd is not supported on the router? We have interfaces configured here: https://github.com/syncloud/rootfs/blob/master/bootstrap/files/common/etc/network/interfaces

[thomasschaeferm]

dhcp for ipv6 is completely different compared to ipv4. At the moment you ignore ipv6, so it is only configured by slaac, but without dns-resolver. The interfaces file, you linked, contains the inet6 entry. My fresh install from one of your images doesn't contain that option. In future versions you should also find a way to get IPv6-resolvers (usually via SLAAC RFC 8106 and or dhcp-info). I found this link: https://wiki.debian.org/IPv6PrefixDelegation That means, if you update your base, much things are getting easier.

[thomasschaeferm]

If the PD-request fails, nothing should happen - except you can't use the second prefix. Then I would recycle parts of the existing prefix, described some comment earlier (/112 with proxy)

[cyberb]

I am trying to build new image based on Debian buster with the changes in the above commit. Arm image does not boot yet. Will try x64 image.

[cyberb]

Ok here are the images:

x86: https://github.com/syncloud/platform/releases/download/untagged-c3b5b8e9ffe50a63b63f/syncloud-amd64-buster-20.04.img.xz

Odroid HC1/2: https://github.com/syncloud/platform/releases/download/untagged-c3b5b8e9ffe50a63b63f/syncloud-odroid-xu3and4-buster-20.04.img.xz

Network interface has eth1 for a second prefix: https://github.com/syncloud/rootfs/blob/master/bootstrap/files/distro/buster/etc/network/interfaces Could you boot it and see if you get eth1 up automatically, I am not sure how it should work.

[thomasschaeferm]

I get 404.

[cyberb]

Sorry, draft was not visible.

x86: https://github.com/syncloud/platform/releases/download/20.04-rc1/syncloud-amd64-buster-20.04.img.xz

Odroid HC1/2: https://github.com/syncloud/platform/releases/download/20.04-rc1/syncloud-odroid-xu3and4-buster-20.04.img.xz

All available here: https://github.com/syncloud/platform/releases/tag/20.04-rc1

[thomasschaeferm]

Now with raspi4 image? Or is it a mistake?

[cyberb]

What do you mean exactly? You can get rpi images from here: https://github.com/syncloud/platform/releases/tag/20.04-rc1

[thomasschaeferm]

You wrote "Arm image does not boot yet." Is it solved now?

[cyberb]

Currently only buster (Debian buster) images have eth1 with prefix delegation. I was not sure if Jessie supports that, but I will try that before the final release.

[cyberb]

You wrote "Arm image does not boot yet." Is it solved now?

It is all good now :) all the boards should work.

[thomasschaeferm]

I am little bit confused. Our aim is: to get a prefix (via eth0) and to use that prefix in openvpn. What is the purpose of eth1? What should I test here? Is eth1 the test interface for requesting a prefix via dhcp-pd or should I connect other devices to eth1 and look, if the devices get an ip of that additional prefix. (like later the openvpn clients?)

[cyberb]

Right I am not sure how it should work either.

So the doc said:

This how-to merely covers requesting a prefix via DHCPv6 on one network interface and assigning that prefix to another.

That is why I thought we need this second interface to hold the second prefix. So later OpenVPN can use it (not done yet). So I thought we can test if our network setup works and it can obtain correctly a prefix.

If you think we do not need eth1, how OpenVPN can obtain a prefix without it? Just by executing DHCP client directly?

[thomasschaeferm]

via the "hooks", now I try to start the images...

[thomasschaeferm]

After a lot of trouble with the mess of eth0/eth1 (it was not stable, udev-rule did not work...) and the change from "dhcp" to "auto" - it works as expected Now, I think, it is time to change the script in that way, that it doesn't configure an useless eth1, instead it configures "server-ipv6" of the openvpn server

ip-a.txt ip-r.txt jounal.txt dhclient-script.debug.txt

[cyberb]

After a lot of trouble with the mess of eth0/eth1 (it was not stable, udev-rule did not work...) and the change from "dhcp" to "auto" - it works as expected

Re-uploaded x64 and rpi4 images with the auto fix.

Now, I think, it is time to change the script in that way, that it doesn't configure an useless eth1, instead it configures "server-ipv6" of the openvpn server

Which script? DHCP? (https://github.com/syncloud/rootfs/blob/master/bootstrap/files/common/etc/dhcp/dhclient-exit-hooks.d/prefix_delegation)

[thomasschaeferm]

That script.

[cyberb]

Ok, you think I should change the script to do the following things:

1. Add/remove "server-ipv6" according to DHCP event
2. Restart OpenVPN service

And remove eth1.

[thomasschaeferm]

Yes, so or similar. Of course not on every event. If prefix is the same, it would not be good to restart openvpn. If the prefix changes, you already lost all clients. Then the ovpn server has to restart. You have probably to reduce the prefix. Depending on user's router you may get /56 .../64, OpenVPN needs just a /112

[cyberb]

Ok, removed eth1:

• https://github.com/syncloud/platform/releases/download/20.04-rc1/syncloud-amd64-buster-20.04.img.xz
• https://github.com/syncloud/platform/releases/download/20.04-rc1/syncloud-raspberrypi4-buster-20.04.img.xz

Then install latest OpenVPN:

snap refresh openvpn --channel=master

It will add this DHCP hook: https://github.com/syncloud/openvpn/blob/master/bin/prefix_delegation.sh

[thomasschaeferm]

After spending some hours of testing: good progress, but it still fails. The hook-script seems to have a problem, which I cannot solve. Apr 19 15:20:21 syncloud sh[408]: /sbin/dhclient-script: 7: /etc/dhcp/dhclient-exit-hooks.d/openvpn: [[: not found Apr 19 15:20:21 syncloud sh[408]: sed: -e expression #1, char 53: unknown option tos' ` If I copy manually the prefix (caught by the debug function) and restarting openvpn, then it works. I had some trouble with other things. For instance, you did not add the IPv4-default route. That confused me a little bit. Another very annoying thing is your dns-handling. The openvpn client has often tried to connect to my private IPv4 address. I think it should not published via DNS. It is useless in public IPv4-networks as well in IPv6-only environments.

journal-20200419.txt.gz

[cyberb]

Fixed the error, please refresh:

snap refresh openvpn --channel=master

Could you propose fixes to the config as I have tried many things and not sure if it is correct now:

https://github.com/syncloud/openvpn/blob/master/config/web/openvpn-server-config.tpl

[thomasschaeferm]

Despite the initial problem ( I have to wait for a prefix change, respectively I have to change the prefix by restarting my router ) the hook script is now running. But the result doesn't fit to my expectation.

The right entry is commented by # also a space is missing

Sorry for discussion about DNS(*.syncloud.it) and default routes (split tunneling versus complete tunneling) . This should be discussed in separate issues. logfiles.zip

[cyberb]

Strange, latest version should update it properly. Could you run this:

new_ip6_prefix='2001:123:456::/61' reason='BOUND6' /snap/openvpn/current/bin/prefix_delegation.sh 

Then test:

cat /var/snap/openvpn/current/openvpn/server.conf | grep server-ip

Should print this:

server-ipv6 2001:123:456::/61

[thomasschaeferm]

I did the tests you suggested. logfiles-20200421.zip

[cyberb]

Ok apart from not real IPv6 and /61 issue the script seems to set ipv6 correctly and there is no # or missing space. So does it actually set real ipv6 when you restart your router?

[thomasschaeferm]

If I call it manually (new_ip6_prefix=... old_ip6_prefix ....) it is correct. But in case of a real prefix change by the router the result is still corrupt. At the moment I have no idea. Within the next days I could install the image and the snap master package to my raspberry pi and share my account with you, so you can investigate it. In that case you have to call/email/... me to reconnect the router. I can do that remotely at any time. Your DNS-update is fast enough. The recognition of the prefix change may need 20 minutes or more. In case you agree, send me your public ssh key. You need IPv6 of course, I have no public IPv4 anymore.

[cyberb]

Just pushed another version with some syslogs and a cleanup on disable event (https://github.com/syncloud/openvpn/commit/57dcc7ec1813850cab99a3e4a6937783c6c1f1bf).

Could you refresh:

snap refresh openvpn --channel=master

Or if it refresh fails

snap remove openvpn
snap install openvpn --channel=master

Then change router settings and check syslog:

root@syncloud:~# grep openvpn-ipv6 /var/log/syslog
Apr 22 12:49:03 syncloud openvpn-ipv6: enable ipv6: 2001:123:456::/64
Apr 22 12:49:05 syncloud openvpn-ipv6: enable ipv6: 2001:123:456::/64
Apr 22 12:49:06 syncloud openvpn-ipv6: enable ipv6: 2001:123:456::/64

[thomasschaeferm]

The result is: grep openvpn-ipv6 /var/log/syslog Apr 22 15:05:45 syncloud openvpn-ipv6: disable ipv6: 2001:a61:576:7efc::/62 Apr 22 15:05:45 syncloud openvpn-ipv6: disable ipv6: 2001:a61:5a5:57fc::/62 logfiles-20200422.zip

[thomasschaeferm]

syslog-raspi.20200422.zip

In the meantime on my raspi: Apr 22 18:16:30 syncloud openvpn-ipv6: event reason: BOUND6, new_ip6_prefix: 2001:a61:5a5:57f4::/62, old_ip6_prefix: 2001:a61:5a5:57f4::/62 Apr 22 18:16:30 syncloud openvpn-ipv6: event reason: BOUND6, new_ip6_prefix: 2001:a61:5aa:39f4::/62, old_ip6_prefix: Apr 22 18:16:30 syncloud openvpn-ipv6: enable ipv6: 2001:a61:5aa:39f4::/62

both systems (x86_64, armv7l) use the debian image you provided 3 days ago and openvpn snap 200422110 (x86_64) 200422111 (armv7l)

[cyberb]

Sorry I was about to tell you there is a new version with a bit simplified bash if statements and more logs (http://ci.syncloud.org:8080/link/syncloud/openvpn/commit/39ffacd9f503a9739dc47767974ae2b441516421)

You can try in amd64 as well.

[thomasschaeferm]

journals-syslog-amd64-raspi-200422112.zip

each with two successful prefix changes. But I could not test routing to the client - the prefix length is still wrong.

[cyberb]

you get /62 prefix, is this normal? is this coming from the router? openvpn says it only supports 64 to 112.

[thomasschaeferm]

There is no "normal". Everything is possible between usually /48 and /64. An other device in my network fetches /60 . I don't know if the /62 results by the debian's or my router's preferences. Anyway, you can just use the first /64 of whatever you get. The simplest way would be to replace "/*" to "/64"

[cyberb]

just push another version with condition-less conversion to 64. do I need to check if prefix is less then 64 and fail if it is not?

[thomasschaeferm]

I am not sure. (RFC are long and practical experience is often a different story , https://tools.ietf.org/html/rfc8415 ) I don't expect strange prefix lengths. But it doesn't harm much, if you include a check for the minimum requirements of openvpn (/112) - and if someone in a rare case provides only a /96 or what ever, but enough for an /112 - it shouldn't fail

[cyberb]

so I should do something like this probably:

1. if below 64: change to 64
2. if above 112: fail

I should not change 64-112 range (I do right now)

Correct?

[cyberb]

done, check latest version. does ipv6 openvpn actually work now?

[thomasschaeferm]

Looks good! For me it works. I am not sure, how the initial behavior is - even if the prefix never changes. client-android.log journal-raspi-200424115.log

[klmhsb42]

Nice work. Let me know, if I should test it, too (if I can update from app store). Could you you tell me, what I would have to change in the router settings?

Do I need to check:

Additional IPv6 Routers in the Home Network [ ] Allow IPv6 prefixes announced by other IPv6 routers in the home network

And:

DHCPv6 Server in the Home Network ( ) Assign DNS server and IPv6 prefix (IA_PD)

If I would change it, there is also some "warning" The procedure requires extra confirmation. which I can confirm by a button on web UI and on the router, I guess. Never done that.

[thomasschaeferm]

My pleasure did not last very long. Now I have a problem. I am not sure, if it's on syncloud or my router.

No, do not allow that. Additional IPv6 Routers in the Home Network [ ] Allow IPv6 prefixes announced by other IPv6 routers in the home network

That is necessary: DHCPv6 Server in the Home Network (*) Assign DNS server and IPv6 prefix (IA_PD)

[thomasschaeferm]

Something changed the server.conf back to "#server-ipv6" journal-raspi.txt syslog.txt

--weekend--

[cyberb]

Apr 24 14:46:53 syncloud openvpn-ipv6: event reason: EXPIRE6, new_ip6_prefix: , old_ip6_prefix: ***5f8::/62
Apr 24 14:46:53 syncloud openvpn-ipv6: disable ipv6

Apr 24 14:46:54 syncloud openvpn-ipv6: event reason: RENEW6, new_ip6_prefix: ***:bef8::/62, old_ip6_prefix: ***:bef8::/62

Apr 24 15:16:55 syncloud openvpn-ipv6: event reason: RENEW6, new_ip6_prefix: ***:bef8::/62, old_ip6_prefix: ***:bef8::/62

Looks like something else is expired, probably I can save current ip and use it to check what is expiring or changing to not disable randomly.

[cyberb]

Another version with the fix for unrelated expiry.

@klmhsb42 Currently this version is on master channel:

snap install openvpn --channel=master

[klmhsb42]

Does work for me only on my Windows10 PC, but not on my android phone (I have IPv6 without VPN connection by WiFi). Client logs to support mail. It's also randomly connecting by IPv6 or local IPv4. However, this doesn't make a difference in the result...

That is necessary: DHCPv6 Server in the Home Network (*) Assign DNS server and IPv6 prefix (IA_PD)

I did.

snap install openvpn --channel=master

I did.

[cyberb]

Could you send:

grep openvpn-ipv6 /var/log/syslog

Are you on latest buster image?

[klmhsb42]

Are you on latest buster image?

Oh, I forgot, do I have to re-install?

[cyberb]

Yes as for IPv6 prefix delegation I had to change network configuration which is part of the image. I would test on a separate device/VM as not all the apps work on buster image yet like diaspora (I am working on it). New Jessie image will also be there for testing soon (if prefix delegation works on it) but I will probably drop it at some point.

[klmhsb42]

Is it still 20.01 VM image?