Wireguard - missing wg-quick

Turris Omnia - rtrom01
Turris OS 3.9.6
Kernel 4.4.119-082ea0f4a4e204b99821bedcb349ed54-0
kmod-wireguard 4.4.119+0.0.20171017-…4-0
wireguard 0.0.20171017-1
wireguard-tools 0.0.20171017-1

wg-quick appears to be absent considering

# wg-quick
-ash: wg-quick: not found


@lampra I read that thread but there was no mentioning of wg-quick, whose functionality does not seem to be covered with the luci-app-wireguard.

And looks like that latter did not make it even into TO 3.10 and is now scheduled for 4.0 with a stable production release towards end of this year…
Whilst in the meantime WG released 0.0.20180304 and there is no sign of it appearing in TO

wg-quick is not present at all in the LEDE/OpenWRT packages, even upstream.

wondering why it is being omitted considering that wg is reportedly making inroads to be baked into the Linux ML kernel via systemd

wg-quick depends on bash. That is not the default shell in OpenWRT/LEDE. BTW, the WireGuard author is actively involved in the OpenWRT packaging.

@einar it may not be default shell but a bash package is available at the TO repo (and upstream). Thus cannot see a reason that wg-quick should be absent, say installing the bash package as dependency if not already installed.

wg-quick is just a utility to try wireguard on any unix like system. My opinion is that you shouldn’t be using it for permanent deployment. And wireguard is designed so that it’s expected that you will use it together with your standard network configuration. So there should probably be some module for networkmanager (I don’t know I am not using nm). I am using netifrc and wireguard is integrated pretty well with it. In OpenWRT there is support for netifd. You can configure it in /etc/config/network as any other interface. Problem is that I don’t know about any documentation for that at the moment. My use is reverse engineered from /lib/netifd/proto/wireguard.sh. It’s not that complicated script so you can found out what you can configure directly from it with ease.

@cynerd thanks for the input but maybe I am shortsighted since fail to see that netifd has the ability of wg-quick to execute shell (bash) script snippets before/after setting up/tearing down the interface like PreUp, PostUp, PreDown, PostDown and subsequent add/del ip routes and/or ip/nftables. Which is rather simple but powerful and convenient.
/lib/netifd/proto/wireguard.sh does not cater for those shell script snippets.

Or do I miss something here about netifd? Else I would not be so quick to discard wg-quick.

No you are not missing anything. To my knowledge (but I wasn’t investigating it) there are no shell hooks in netifd. But unless you want to do something crazy then netifd should be all what you need. It supports additional routes. Adding interface to firewall zone it also automatically handles iptables. If you need some weird hook then try to contact upstream if they can add some hook for it.
I am not sure in what state are nftables in OpenWRT but I suspect that there is no deep support. I think that if you want to do such change then you have to reimplement OpenWRT firewall to nftables. Unless you do that only other option is to just throw away whole network configuration of OpenWRT and build your own. Depends on what you want.

@cynerd I am not sure that (b)(a)(sh) hooks are uncommon (or weird/crazy) in (VPN) network configurations, e.g. to deploy the so-called ‘‘kill-switch’’, in order to prevent the flow of unencrypted packets through the non-VPN interfaces or route particular clients, setting DNS, gateway, start/stop ipforwarding in sysctl etc

I do not know about OpenConnect but OpenVPN has similar script abilities (up, down, client-connect, client-disconnect) albeit more circumvent and less convenient than WG.

So whilst that ability is not dismissed/castrated in OpenVPN it is for WG for some reason.

I am not a fan of having network routing in a ‘firewall’ (which is a network protection based on netfilter) but do the routing where it belongs - the network settings, preferably through ip route and then nf/iptables (whether nftables or iptables is not the point).

You can do “kill-switch” with firewall and that is I would say even better as you have no guaranty that you won’t leak unencrypted packets with shell hooks. And if you need some dynamic disconnects or connects then you are working in let’s say laptop use case not router. But setting DNS, gateway, ipforward, all that is handled by netifd machinery.
Man I am not saying that it’s good that you have no such option. You can try to look for it, I wasn’t. You don’t have to convince me, I don’t like setup that is in OpenWRT. I am more keen to what I use on my servers (netifrc) implemented purely in shell and integrated as system services. But netifd is what is on router at the moment and I am telling you that you are trying to look for something that is not there. And that you should try to do it netifd way unless you want to just get rid of netifd completely.

What you are talking about network routing in firewall? There is no such thing. You configure routing and according to that routing when packet is send trough one of links it’s checked by firewall which optionally does some packets manipulation. But firewall is not able and never does any routing. You might be confused about what firewall really does which is questionable when you are trying to use nftables here.

That is static but not dynamic as the firewall does not check whether a route is up/down.

When implementing an ip route and/or nf/iptable through a shell hook it is the same as via the firewall, either hooking into netfilter through a script.

Your point taken but it is hardly a universal truth since there are also dynamic scenarios in a router, even if your end everything is static.

Indeed, but only static and not dynamic.

It is there in OpenVPN, like stated earlier. Not sure why you are vehemently dismissing it?

I am fine thank you. Trust that mixing firewall into this is straying from the subject though.

No it’s not and it’s not good to think so. If you have it configured well in firewall then there is no leakage at all. If you have configuration that is based on shell hooks that drop or add some route when link goes down or up then there is no guaranty that your script is executed before kernel starts sending packets different way according to your old routing rules. You can have routes configured so that there is no leakage possible even with shell hooks but in general shell hooks won’t ensure you that there will be no leakage. My opinion is that it’s better to use firewall instead of creating some shell rules. But shell hooks has their place too. But it’s not definitely in no-leakage guarantee.

Because we are talking here about wireguard not openvpn. And because openvpn has completely different implementation than wirteguard.
But why I am dismissing it? Because I read /lib/netifd/proto/wireguard.sh and as you can see:

proto_wireguard_teardown() {
  local config="$1"
  ip link del dev "${config}" >/dev/null 2>&1

There is no call to any hook. It also doesn’t contain any option with such hook. And netifd doesn’t seems to support it for generic interface Network configuration [Old OpenWrt Wiki]. I don’t understand why you still trying to bargain with me. I am telling you what I know and if you don’t like it then try to look at it on your own as I told you so multiple times already. Telling me that what I am writing has to be wrong won’t change it. If you have evidence that I am wrong then I am open to it.

Correct me if wrong but the firewall is not aware whether a particular (VPN) route is up/down and it requires a script or deamon to monitor the connection state and take action (kill switch via script) when the route is down. Common scenario with split routing where some clients are routed trough the ISP’s WAN and some through the VPN.

OpenVPN was brought in as comparision of not being curtailed and having such up/down script snippets too. Yes, the basic implemention is different but the functionality of shell script snippets is similar.

I am not sure whether you made the effort to read into wg-quick and the abilities. It is greatly enhancing the basic wireguard.sh and not shell hooking but making similar system calls, e.g. you can

PreUp = ip route add x.x.x.x./x via x.x.x.x.
PreUp = iptables -A …
PostUp = ip link add dev …
PostDown = systemctl -w net.ipv6.conf.all.disable_ipv6 = 1

No weird hooks, just common shell script calls to the system environment.

Whether I like it is beside the point, just what are you arguing resonates as not certain whether you actually looked into wg-quick. As you are however open to it I would hope that you do.

If you have issues with the lack of wg-quick, bring it upstream to LEDE (not LEDGE, BTW). There’s nothing that can be done here (TurrisOS is a sort of downstream in this case).

@einar TO is on the router and not LEDE. Why there is nothing that can be done in this repo since it is not a 1:1 copy of LEDE but features own implementations? Else what would be point of the TO repo if not tailoring the upstream repo?

Why would it not be an issue that other VPN solutions, e.g. OpenVPN, come fully featured but WG not?

However, the point has been made clear by now that there is apparently no interest (rather oppsing it) and that is fine then.

Ask the LEDE developers. The WireGuard package in TurrisOS is, AFAICS, a backport of what’s in LEDE officially now.

@einar you made your point and it has been conceeded albeit you keep on dismissing that this about TO and not LEDE. You make it sound like the TO team has no mind/agenda of their own to implement/discard things differently from the upstream repo, if they wanted/cared to.

If TO was a 1:1 copy of LEDE there would be no point in TO at all, or?
And if there was LEDE on the router I would certainly refer to them and not to TO.

Reckon that any further discussion would be mute and thus perhaps better to rest the subject.

Came across this WG mailing list entry

I assume youre not shipping the bash completion stuff either, right? Since openwrt doesn’t use bash.

We are not shipping it.

That is dating back to JAN 2017.
Which is strange as the BASH package is available in OpenWRT since at least AUG/SEPT 2014. Perhaps there is an issue with the BASH implementation (busybox) in OpenWRT and BASHCOMPLETION required for wg-quick