Great, thanks for testing.
Thanks a lot for adding wireguard module to the last build !
I confirm it works like a charm.
@sam_nazarko is it possible iptables connmark target is missing from the kernel?
WireGuard works fine, until I try to route all traffic through WG. It crashes on an iptables error. WireGuard dev thinks it’s connmark.
It’s there in kernel 3.14.29-157.
Looking through the WireGuard documentation I see at least five different method described.
That’s a bit short on detail. Please describe in more detail what you are doing, show all error messages, and provide full logs (
I’ve checked this.
# Xtables combined modules # CONFIG_NETFILTER_XT_MARK=y CONFIG_NETFILTER_XT_CONNMARK=y
Here is our complete configuration: https://paste.osmc.tv/raw/jugefiwona
Yes I believe there are several ways of routing traffic, but ideally I’d want to use
wg-quick. The error happens at this line in the script:
echo -n "$restore" | cmd $iptables-restore -n under
add_default(). Note that it’s only a problem when redirecting all traffic through WireGuard (
AllowedIPs = 0.0.0.0/0).
So the error was pretty non-descriptive: something along the lines of
iptables-restore: error on line 3 and would crash
Comparing a Debian (amd64) I’ve noticed that the following packages were only partly installed:
iptables libip6tc0 libiptc0 libjansson4 libnetfilter-conntrack3 libnfnetlink0 libnftables0 libnftnl11 nftables
I tried to install them one by one.
nftables the error goes away but the tunnel remains offline.
It seems like
libnftables0 doesn’t exist, but similar package exists named
libnftables1. Installing that one causes issues though:
root@osmc:/home/osmc# apt install libnftables1 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libnftables1 : Depends: libc6 (>= 2.28) but 2.24-11+deb9u4 is to be installed Depends: libxtables12 (>= 1.6.1) but 1.6.0+snapshot20161117-6 is to be installed E: Unable to correct problems, you have held broken packages.
Logs are at https://paste.osmc.tv/catirumufu
One thing that strikes me immediately is that wg-quick is part of the wireguard-tools package, which is only available in buster-backports (and unstable). Since OSMC is still on Debian stretch, such unmet dependencies are very likely to occur.
I’ll take a more in-depth look this evening.
That’s indeed the case.
I think for now the Wireguard tools should probably be built from source until we move to Buster
My own feeling is that you should wait for OSMC to move to Debian buster before using wg-quick. There are several other methods you can use in the interim. That said, there’s nothing to prevent you from seeing what’s wrong with $restore. Just add a line before the failing command
echo "$restore" > /tmp/zzz.out and see what it contains.
I had an inkling that it might have been the lack of the mangle table, but I see that Sam has added it to 4.9.
I also see that you have an IP address on both eth0 and wlan0, so how do you control which interface is used by WG?
Oh I didn’t realise osmc wasn’t running Debian 10. When is it planned to move to Buster?
I believe WireGuard automatically selects an iface. I assumed preferred is wired. This doesn’t seem to be a problem on any other devices.
I can’t seem to get it to work on my OSMC – it’s okay, I’ll use my iPad for now (the whole idea was to watch some local content/news from my home country during the lockdown while being in Singapore).
We will move when Buster is ready.
For now you would probably have to compile the client tools from source.
I think that « wg-quick » rely on nftables. But for this to work correctly, we need the kernel module « nf_tables ».
And from current 4.19 osmc kernel the following config is disabled :
grep NF_TABLES /boot/config-4.9.113-19-osmc # CONFIG_NF_TABLES is not set
Is this possible to try to update kernel with this enable (as a module) ?
Thanks a lot,
I will add it for the next kernel.
To use wg-quick you must change the code of wg-quick (is a script) and from the config file (e.g. wg0.conf). You can use nano for this.
iptables can not use the -m function. You must set the firewall without it.
If the problem with iptables is solved, then you can reinstall wireguard-tools.
Before (begin at line 232):
printf -v restore '%sCOMMIT\n*mangle\n-I POSTROUTING -m mark --mark %d -p udp -j CONNMARK --save-mark %s\n-I PREROUTING -p udp -j CONNMARK --restore-mark %s\nCOMMIT\n' "$restore" $table "$marker" "$marker" printf -v nftcmd '%sadd rule %s %s postmangle meta l4proto udp mark %d ct mark set mark \n' "$nftcmd" "$pf" "$nftable" $table printf -v nftcmd '%sadd rule %s %s premangle meta l4proto udp meta mark set ct mark \n' "$nftcmd" "$pf" "$nftable" [[ $proto == -4 ]] && cmd sysctl -q net.ipv4.conf.all.src_valid_mark=1 if type -p nft >/dev/null; then cmd nft -f <(echo -n "$nftcmd") else echo -n "$restore" | cmd $iptables-restore -n fi
#printf -v restore '%sCOMMIT\n*mangle\n-I POSTROUTING -m mark --mark %d -p udp -j CONNMARK --save-mark %s\n-I PREROUTING -p udp -j CONNMARK --restore-mark %s\nCOMMIT\n' "$restore" $table "$marker" "$marker" printf -v nftcmd '%sadd rule %s %s postmangle meta l4proto udp mark %d ct mark set mark \n' "$nftcmd" "$pf" "$nftable" $table printf -v nftcmd '%sadd rule %s %s premangle meta l4proto udp meta mark set ct mark \n' "$nftcmd" "$pf" "$nftable" [[ $proto == -4 ]] && cmd sysctl -q net.ipv4.conf.all.src_valid_mark=1 if type -p nft >/dev/null; then cmd nft -f <(echo -n "$nftcmd") else echo "test" #echo -n "$restore" | cmd $iptables-restore -n fi
I’ve updated the 4.9 kernel configuration and this will be reflected in the next build. It should be noted that it will be a few weeks until another build is pushed.
diff --git a/.config b/.config index 51786ce..5e1bf97 100644 --- a/.config +++ b/.config @@ -749,7 +749,30 @@ CONFIG_NF_NAT_IRC=y # CONFIG_NF_NAT_SIP is not set # CONFIG_NF_NAT_TFTP is not set CONFIG_NF_NAT_REDIRECT=y -# CONFIG_NF_TABLES is not set +CONFIG_NF_TABLES=y +CONFIG_NF_TABLES_INET=y +CONFIG_NF_TABLES_NETDEV=y +CONFIG_NFT_EXTHDR=y +CONFIG_NFT_META=y +CONFIG_NFT_NUMGEN=y +CONFIG_NFT_CT=y +CONFIG_NFT_SET_RBTREE=y +CONFIG_NFT_SET_HASH=y +CONFIG_NFT_COUNTER=y +CONFIG_NFT_LOG=y +CONFIG_NFT_LIMIT=y +CONFIG_NFT_MASQ=y +CONFIG_NFT_REDIR=y +CONFIG_NFT_NAT=y +CONFIG_NFT_QUEUE=y +CONFIG_NFT_QUOTA=y +CONFIG_NFT_REJECT=y +CONFIG_NFT_REJECT_INET=y +CONFIG_NFT_COMPAT=y +CONFIG_NFT_HASH=y +CONFIG_NF_DUP_NETDEV=y +CONFIG_NFT_DUP_NETDEV=y +CONFIG_NFT_FWD_NETDEV=y CONFIG_NETFILTER_XTABLES=y # @@ -845,12 +868,20 @@ CONFIG_NETFILTER_XT_MATCH_U32=m # CONFIG_NF_DEFRAG_IPV4=y CONFIG_NF_CONNTRACK_IPV4=y +CONFIG_NF_TABLES_IPV4=y +# CONFIG_NFT_CHAIN_ROUTE_IPV4 is not set +CONFIG_NFT_REJECT_IPV4=y +# CONFIG_NFT_DUP_IPV4 is not set +# CONFIG_NF_TABLES_ARP is not set # CONFIG_NF_DUP_IPV4 is not set # CONFIG_NF_LOG_ARP is not set # CONFIG_NF_LOG_IPV4 is not set CONFIG_NF_REJECT_IPV4=y CONFIG_NF_NAT_IPV4=y +# CONFIG_NFT_CHAIN_NAT_IPV4 is not set CONFIG_NF_NAT_MASQUERADE_IPV4=y +# CONFIG_NFT_MASQ_IPV4 is not set +# CONFIG_NFT_REDIR_IPV4 is not set CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PPTP=m # CONFIG_NF_NAT_H323 is not set @@ -881,11 +912,18 @@ CONFIG_IP_NF_ARP_MANGLE=y # CONFIG_NF_DEFRAG_IPV6=m CONFIG_NF_CONNTRACK_IPV6=m +CONFIG_NF_TABLES_IPV6=y +# CONFIG_NFT_CHAIN_ROUTE_IPV6 is not set +CONFIG_NFT_REJECT_IPV6=y +# CONFIG_NFT_DUP_IPV6 is not set # CONFIG_NF_DUP_IPV6 is not set CONFIG_NF_REJECT_IPV6=y # CONFIG_NF_LOG_IPV6 is not set CONFIG_NF_NAT_IPV6=m +# CONFIG_NFT_CHAIN_NAT_IPV6 is not set CONFIG_NF_NAT_MASQUERADE_IPV6=m +# CONFIG_NFT_MASQ_IPV6 is not set +# CONFIG_NFT_REDIR_IPV6 is not set CONFIG_IP6_NF_IPTABLES=m # CONFIG_IP6_NF_MATCH_AH is not set # CONFIG_IP6_NF_MATCH_EUI64 is not set @@ -906,6 +944,7 @@ CONFIG_IP6_NF_RAW=m CONFIG_IP6_NF_NAT=m CONFIG_IP6_NF_TARGET_MASQUERADE=m CONFIG_IP6_NF_TARGET_NPT=m +# CONFIG_NF_TABLES_BRIDGE is not set # CONFIG_BRIDGE_NF_EBTABLES is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set
Has anyone put together a step by step tutorial on how to set this up?
Not yet - it’s quite involving and depends on your local network configuration.
Hey Sam – Read in this thread that Buster support is technically ready? How best to upgrade? I don’t mind testing.
Note (don’t know if that matters) – but I added the
deb http://apt.osmc.tv videoimprovevero main line as explained here to update to kernel. Currently running
Linux osmc 4.9.113-20-osmc #1 SMP PREEMPT Fri May 15 17:37:55 UTC 2020 aarch64 GNU/Linux
Buster and the 4.9 kernel are not compatible currently, once Buster is ready for OSMC it’ll first be available for the currently supported kernel and then work will be underway to merge the two.
Hi, now when we have released OSMC based on Debian Buster and support for wireguard (acording this thread https://discourse.osmc.tv/t/testing-linux-4-9-kernel-and-improved-video-stack-for-vero-4k-4k/84874),
can someone post basic tutorial how to install and configure wireguard on OSMC, please? Thanks