Hi everyone,
I created a LuCi integration for Wireguard. Feedback and beta testing appreciated.
–> https://github.com/danrl/luci-proto-wireguard
Thanks
PS: Once it is in the official openwrt repo, how long will it take to be available to my omnia? What is the usual workflow and delay there?
Great work!!! I’ve been configuring wireguard up to now via the command line. Can’t wait to try this.
Any update on this? Would love to try this out 
It is in LEDE. But Omnia is lagging behind the official repos.
https://www.danrl.com/2016/11/16/openwrt-luci-proto-wireguard.html
Allright, I’ll look into building it myself for the time being. Should be a fun exercise.
Is there any way we can speedup the process of the package being included in the the turris repo’s?
Unfortunately, there is no way to speed it up. This is the official response I got: https://github.com/CZ-NIC/turris-os/issues/11
Patience
I’m having issues creating a wireguard interface with your luci-app-wireguard application. I fill out the fields for protocol, private key, port, and ip address --then hit save, I get the following error.
/usr/lib/lua/luci/dispatcher.lua:460: Failed to execute arcombine dispatcher target for entry ‘/admin/network/network/wireguard’.
The called action terminated with an exception:
/usr/lib/lua/luci/cbi.lua:165: Datatype error, bad token "base64"
stack traceback:
[C]: in function ‘assert’
/usr/lib/lua/luci/dispatcher.lua:460: in function ‘dispatch’
/usr/lib/lua/luci/dispatcher.lua:141: in function </usr/lib/lua/luci/dispatcher.lua:140>
It doesn’t seem to like the base64 encoded private key. I’m a definitely using base64 key. Have you seen this error before?
LEDE and TurrisOS are diverging fast. Unfortunately, the Turris team has not yet finished upstreaming hardware support. I can’t really support running current software on an outdated and diverging OS. Many things change from release to release and they change for a good reason.
That said, here is what I think you are running into:
The error you are getting is most likely due to an outdated ‘datatypes.lua’ file. Find it and compare it with upstreams. You are missing at least one datatype: ‘base64’
Please note that it will get increasingly harder to backport LEDE packages to TurrisOS and that it is not supported.
PS: You may also like luci-app-wireguard for a fancy overview of tunnels and status information. I released it a while ago.
actually, I was more interested in seeing how you implemented the “start at boot” feature. I wrote my own service config, but it’s not 100% reliable --more like 80-90%, every once in a great while the service doesn’t start at boot.
Here’s what I have for /etc/init.d/wireguard, how could I improve this?
#!/bin/sh /etc/rc.common
START=95
STOP=10
boot() {
sleep 20
start
}
reload() {
wg setconf wg0 /etc/wireguard.conf
}
restart() {
stop
sleep 1
start
}
start() {
ip link add dev wg0 type wireguard
ip address add 192.168.10.10/24 dev wg0
wg setconf wg0 /etc/wireguard.conf
ip link set up dev wg0
ip route add 192.168.1.0/24 via 192.168.10.10 dev wg0
ip route add 192.168.2.0/24 via 192.168.10.10 dev wg0
}
stop() {
ip route del 192.168.1.0/24 via 192.168.10.10 dev wg0
ip route add 192.168.2.0/24 via 192.168.10.10 dev wg0
ip link del dev wg0
}
Throw it away and use netifd. This is how it is meant to be. init scripts are not the right place for firing up interfaces, as they may go untracked there.
Sorry to say that, but I have little interest in supporting WireGuard on TurrisOS. WireGuard is still in development, it is fast moving, and so ist LEDE. TurrisOS is just too slow to keep up with that. We better wait for their upstreaming efforts to produce results and then build LEDE for Omnia. That said, feel free to backport WireGuard to TurrisOS. I really recommend using the netifd and proto-handler approach instead of init scripts.
I’ll create a config this weekend following the example listed here:
https://lede-project.org/docs/user-guide/tunneling_interface_protocols#static_addressing_of_wireguard_tunnel
Although, I’m not quite following that example. Not sure why they have two ‘wireguard_foo’ interfaces configured. Pretty sure it’s a typo…anyways, thanks for the advice.
It’s not a typo. Look at the netifd helper (wireguard.sh) to understand why. I wrote that documentation
Anyway, good luck with the very outdated WireGuard on TurrisOS. It might not even connect, since there have been protocol changes since then.
You may want to know (since you repeat this every now and then) that at least there’s a milestone tracking package feed updates for TurrisOS 3.7 (if it hasn’t been pushed back). I’m not from the team, I just read the milestones on their GitLab instance.
Just to point this out.
Wireguard on TurrisOS would be great.
here’s how you can compile the luci-app-wireguard and luci-proto-wireguard packages for turris-os
FROM fedora:25
ENV SDK OpenWrt-SDK-mvebu_gcc-4.8-linaro_musl-1.1.15_eabi.Linux-x86_64
RUN dnf upgrade -y &&\
dnf install -y git wget bzip2 file findutils ccache gcc which unzip automake &&\
wget --no-check-certificate https://api.turris.cz/openwrt-repo/omnia/$SDK.tar.bz2 -P /tmp &&\
mkdir -p /turris/ipk &&\
tar xvjf /tmp/$SDK.tar.bz2 --directory=/turris &&\
rm -rf /tmp/$SDK.tar.bz2 &&\
git clone https://github.com/openwrt/luci.git /turris/openwrt-packages/ &&\
/turris/$SDK/scripts/feeds update lucics &&\
cp -r /turris/openwrt-packages/applications/luci-app-wireguard/ /turris/$SDK/feeds/lucics/applications/ &&\
cp -r /turris/openwrt-packages/protocols/luci-proto-wireguard/ /turris/$SDK/feeds/lucics/protocols/ &&\
ln -s ../feeds/lucics/applications/luci-app-wireguard/ /turris/$SDK/package/luci-app-wireguard &&\
ln -s ../feeds/lucics/protocols/luci-proto-wireguard/ /turris/$SDK/package/luci-proto-wireguard &&\
arm_openwrt_compiler=$(find /turris/$SDK | grep bin/arm-openwrt-linux-g++) &&\
arm_openwrt_ld=$(find /turris/$SDK | grep 'bin/arm-openwrt-linux-ld$') &&\
make CXX=$arm_openwrt_compiler LD=$arm_openwrt_ld V=s -C /turris/$SDK &&\
find /turris/$SDK/ | grep 'luci-app-wireguard.*ipk$' | xargs cp -t /turris/ipk/ &&\
find /turris/$SDK/ | grep 'luci-proto-wireguard.*ipk$' | xargs cp -t /turris/ipk/
CMD ["cp","-r","/turris/ipk/","/tmp"]
to build it:
(put the contents of the previous post in a file called Dockerfile)
docker build -t turris.luci.wg .
docker run --rm -v /tmp:/tmp turris.luci.wg
the following files will now appear in /tmp/ipk on the host system:
luci-app-wireguard_git-17.009.29435-7d19852-1_all.ipk
luci-proto-wireguard_git-17.009.29435-7d19852-1_all.ipk
**in turris-os, you’ll need to replace /usr/lib/lua/luci/cbi/datatypes.lua with the version found here:
(needed for base64 datatype)
**I know it’s a bit hacky, but it’s the better option vs compiling the luci-base package and potentially breaking something
**see this post for instructions on how to build the wireguard packages
There appears to be a minor issue with luci-proto-wireguard
Every time I edit the wireguard settings within luci, the firewall zone reverts back to unspecified.
I don’t see this behavior on my openwrt router, so it’s probably related to some issue in turris-os.
Anyways, once I learned the format for /etc/config/network, I just configured everything there.
what happened with this project? The homepage gives me a 404 now:
https://github.com/danrl/luci-proto-wireguard
otherwise count this as a vote to merge those LEDE changes in TurrisOS!