I just tried the OpenVPN support for the first time and it appears to work great for IPv4, but IPv6 is different. There’s a tun_turris with an IPv4 address assigned and also a link-local IPv6 address. While I am able to reach the other side over IPv4 without issues whatsoever, I am not able to use and IPv6 addresses of the network on the other side.
I tried pinging the link-local address of the omnia from a connected client, but no packets are returned. Ideally I think the link-local address would work and push a route for the fd53 range that is being used on my internal network.
Link-local addresses are not Internet routable you need public IPv6 prefix for it to work. Try using some tunnel broker like HENET to get public IPv6. Also you will have to add new firewall rule for port 1194 to allow input for IPv6 to your public IP and possibly edit opvn configuration file and add remote IPv6 because I am not sure if Reforis adds it?. And you will need IPv6 connectivity on your client for it to work
No, public IPv6 addresses would be needed to establish the VPN connection itself over IPv6. (Both sides have public IPv6 addresses btw. but that’s not the point.)
Once the link is established, tun_turris is the interface used for communication across the VPN connection. This interface has link-local addresses assigned and those should work across the VPN connection link, but for some reason they do not. Only IPv4 traverses through the VPN connection tunnel.
I just checked out the configuration file in /var/etc/openvpn-server_turris.conf and it’s clear that IPv6 is simply not enabled.
There’s a line starting with server and then the IPv4 subnet to be used. To use IPv6 there also needs to be a server-ipv6 line. (Above I was mistaken as a route actually requires a non-link local address assigned to the remote party as well (doh).)
So the Turris module for OpenVPN only switches on IPv4 support. I guess I should look at the code in GitLab and see if IPv6 could be added too. IPv6 is supported for establishing the tunnel, but not passing it inside the tunnel.
Yeah, it should be possible. I’ve been checking out the code:
Right now it’s all about IPv4, but IPv6 could be added. Most ISPs provide a /48 (some provide just a /56), so that should not be a problem. Routing the internal network prefix would also be good.
I hope to find more information on setting up a development environment to work on these projects.
Hello @jschwart,
you can update your OVPN server with this (let’s assume you have the fd7a:2bc0:b1dc::/48 block configured in your router):
Take one /64 subnet from the ULA block that will be used as an address pool for client distribution (for example fd7a:2bc0:b1dc:cafe::/64).
Log in the router through the SSH.
Type in
uci set openvpn.server_turris.server_ipv6='fd7a:2bc0:b1dc:cafe::/64'
uci add_list openvpn.server_turris.push='route-ipv6 fd7a:2bc0:b1dc::/48'
uci commit
service openvpn restart
Try to reconnect with the OpenVPN client and you should have the ULA IPv6 addresses assigned on your tunnel interface and be able to ping other devices on your network.
Cool!!! This gets me further indeed, but not completely yet.
The address is assigned to the remote end, the route is set as well on the remote end, but the tun_turris interface does not have fd7a:2bc0:b1dc:cafe::1 on its interface which seems to be the address used as the endpoint for the route. (This is with br-lan having fd7a:2bc0:b1dc::1. I replaced the network with the one my Omnia picked.)
Ah, I’m on 5.4.2. Maybe that’s the difference. The config on my end seems pretty similar. I’ll wait for 6.0 and see what happens then. Thanks a lot for these hints!!
At the same time I’m still curious on exposing this through the GUI. Does the Turris team have any guide on setting up a development environment to a point where one could run the unit tests of the Python code and possibly run a local copy of (Re)Foris?
Thanks for summoning me here!
Well, right now, I am not the right person to ask because I will have this week and the following week only limited time for work, so only what I can do right now is to point @jschwart to our documentation and also ask other guys, who can help him.
You can try to look at GitLab CI, which we have there and try to follow the steps there, but I think @mmtj would be the right guy to ask about it!
Yes, this is possible, but only on the router. This should help you:
If you have any questions regarding running a local copy of reForis or you run into some issues, @Aleksan4eg will help you with this one.
Sadly, developement setup (developement, running tests, deploy the code on router) of foris-controller is not completely covered in docs, so please take a look at this draft of docs: README-tests (Draft)
If you intend to make changes to the OpenVPN server config, you would at minimum, need to make changes to foris-controller-openvpn-module (low-level reforis backend).
But depending on the scope of the changes, you might as well want to modify the reForis UI.
We don’t have dedicated TurrisOS container image (LXC, docker), so you will have to try the changes on router.
Running the reforis make prepare-dev instruction, I gained a Python virtualenv in which I tried to install the controller. But that controller depends on various things, turris-timezone, turrishw, but also supervisor. That one requires uci.h however, which my Parabola system doesn’t have.
Is there a way to install µCi in that Python venv to let it work? Or could I get supervisor from PyPi? Or should I really do this on another environment?
It might work, at least to certain degree. Perhaps for the hardware independent functionality it could be fine.
But it most likely won’t work for hardware dependent functionality of foris-controller & Turris OS (e.g. network interfaces), as Turris OS is build around certain asumptions about the Turris hardware (NICs, crypto chip, …).
Which would have to be mocked in the container/virtual machine to simulate the Turris hardware.
Besides that, LXC images are currently available only for ARM (aarch64 and armv7l) and PPC architectures, so you would have to run the container on the router anyway.
For development purposes it would be more practical, if there was a way to run Turris OS virtual machine/container on x86 architecture.
For example: In case that you have just one Turris router (deployed as your main router) and then can’t or don’t want to fiddle with the router just for the sake of developement.
Also, unless I am mistaken, there are few pieces missing to make lxc container fully suitable for foris-controller development environment, like passthrough of some hardware (e.g. crypto chip) to the lxc container.
So the way we are developing foris-controller is:
On your computer:
1.1. write the code & tests
2.2 run tests on you computer within heavily mocked test environment
deploy the code to the router and check whether it is really working as expected (i.e. to validate your assumptions in tests and mocks)
Well, we could publish updater-supervisor to the PyPi, but I doubt that it could be much useful to anyone outside of Turris OS.
So best way to get supervisor, is to have uci installed on your Linux system or docker image and let the pip fetch all dependencies.
Unless the foris-controller is direct dependency of some parts of reforis, then I would use separate virtual envs for reforis and foris-controller. That way you will avoid potential mismatch or collisions of their dependencies.
Thanks a lot for all the good pointers. I still intend to follow then and see how it goes. I haven’t been able to get OS 6 running yet unfortunately, I’m still on 5.4.4 at this point. Once I have OS 6 working I intend to look into setting up my dev environment.
It took me a while to move to OS 6 and then look into OpenVPN again, but I can share that it works great with the instructions by @hagrid.
I first tried to take an address from the ULA block and an address from the WAN block, but OpenVPN ended up assigning only the WAN address to itself and my clients. None the less I can access ULA addresses without issues, so I removed those from the OpenVPN configuration again.
if your VPN set-up also routes WAN traffic, don’t take a prefix from the ULA range, but one from the WAN range; it will let you reach ULA addresses on the end as well
and also add uci add_list openvpn.server_turris.push='redirect-gateway ipv6'
This is a good way to have IPv6 connectivity everywhere. I hope I can still look into the other instructions on developing for Turris OS and maybe implement this is nobody beats me to it.
