It is not clear to me whether wg can be configured through uci and/or conventional
Commonly the conventional way it would be a wgX.conf file in the /etc/wireguard/ path and the conf file featuring the [Interface] & [Peer] sections, and supporting additional command like PostUp, PostDown etc.
Is that the way WG is supposed to be configured or should it be done via uci something like below in /etc/config/network
I c, no uci then but the standard convention. Would be helpful if there was some basic documentation on the matter.
The wgX.conf file to be placed in the /etc/wireguard/ path, right?
The question though is how to bring up/down (start/stop) the wg interface without wg-quick (which appears to be absent from the TO repo)? Respectively to start the WG at router boot?
you could use something like this:
ip link add wg0 type wireguard &&
wg setconf wg0 ~/wireguard/wg0.conf &&
ip address add 172.16.0.1/32 dev wg0 &&
ip link set wg0 up &&
ip route add 172.16.0.2/32 dev wg0
begging your pardon for my ignorance but you mean this wg-quick script and to utilize it for router boot time, repectively for stopping/starting wg?
That is certainly some workaround but seems a lot of work when in other linux distros such can be achieved way easier and leaner with wg-quick, e.g.
systemctl enable wg-quick@wgX wg-quick up/down
Why it has to be complex/complicated when there are simple tools available from the upstream vendor but such not being delivered to the TO repo. (sigh)
Yes this is the script, we will need to wait until turris os 4.0 for this functionality.
It seems that turris os developers have other priorities for the moment.
In the mean time, you could probably use your own (simpler) script to bring up the interface at boot time.
Other priorities are cited frequently. Keeping packages in repo updated/complete surely should not be ranking that low, and I am not talking about the luci-app which you are probably referring to.
You don’t need scripts and such. wireguard and wireguard-tools should provide all the functionality.
Example taken from my own configuration:
config interface 'wg0'
option proto 'wireguard'
option listen_port '51820'
list addresses <redacted>
option private_key <redacted>
But then, how do you define peers? They’re defined in the same file with the name wireguard_IFNAME where IFNAME is the interface you defined in the block above (wg0 in this case).
Example:
config wireguard_wg0
option public_key '<host public key>'
# Set the below to 0 if you don't want routes created through the VPN for the allowed IPs.
option route_allowed_ips '1'
# Allowed IPs specified one per line - can be subnets
list allowed_ips '10.64.30.0/24'
list allowed_ips '192.168.40.1/32'
option endpoint_host '<host IP address/name>'
option endpoint_port '51820'
# Use the below only if behind NAT
option persistent_keepalive '60'
@einar thanks for this interesting insight. Wondering how you figured this out as there does not seem to be proper documentation either on TO or upstream at OpenWRT/LEDE
So, after all it is working via uci. Did you try something like PostUp, PostDown etc?
Does it matter where key files are located and how did you get them written into network file as opposed to wgX.conf?
Do you have a practical way to quickly start/stop a wg interface/tunnel considering the absence of wg-quick?
previously but it was not apparent (to me) how the network specifics were constructed/derived except now it dawns that it stems from this blog, utilizing the luci-proto-wireguard.
Latter being absent from TO and it does not seem to generate the keys. The mentioned blog is also not explainig of how to generate the keys. Instead one has to lookup other sources.
With wg-quick absent it castrates wg of a major tool as those script commands make it really easy to manipulate the network as opposed to needing other scripts checking whether a wg interface is up/down and taking action.
Hard to understand why to cripple wg of those capabilities and deliver it half baked to TO/LEDE/OpenWRT considering that, among other things, WG is already lean in code and designed for ease of use as opposed to other VPN behemoths.
Notwithstanding those others, e.g. OpenVPN/OpenConnect/StrongSwan, are delivered from the repo to the user with all features intact and not just some.
Maybe have to see whether it can be compiled from source on a Debian machine and get it working with full capabilities on TO.
Did you
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
and then
cat privatekey and cat publickey?
Yes, right that ought to do it, execept again that wg-quick actions like PostUp/PostDown would require another script.
It’s just a bash script so there is nothing to compile, you can just copy it on router. But see my post in other topic to see why it’s not part of OpenWRT. In short, it’s example usage not intended as primary deployment. Primary deployment in OpenWRT is netifd that is configured trough /etc/config/network.
Look we are at the moment maintaining release on obsoleted version of OpenWRT. Updating packages is our priority but we can’t update everything and there are packages with higher priority and packages with lower priority. If you want to bump some package version then you can do it, test it and then send us patch (for testing compilation you can either use Turris Documentation or Files · master · Turris / myrepo · GitLab). You can also create issue on gitlab or github just to tell us that given packages has newer version, but that doesn’t ensures quick update.
At the moment wireguard is somewhat up to date, at least it has version that is compatible with latest version. If it wouldn’t be then I would bump it on my own us I am using it.
Thank you for this. It seems that you are right. For some reason, the link to lede forum you provide further below never came up on my search:disappointed_relieved:
After setting and partially completing a test for LAN-to-LAN setup, I have been waiting (3 months now) for integration of luci app.
I will try again in the next few days!!!
No other changes done (DHCP etc.). I dont try to enable wg IPv6 yet, I just tried to enable basic VPN with access to the LAN resources. What I am missing here?
option route_allowed_ips '1' sets the routing of all outbound traffic via the WGVPN. If that route is experiencing issues then there will be no traffic.
Is the router the endpoint_host? If not then config wireguard_wg0 requires
option endpoint_host 'public ip of the remote node'
option endpoint_port 'port of the remote node'
I thought, that the wireguarg_wg0 section is for the “client”, if thats correct, then yes, I want to client using only VPN when connected…
The router (Omnia) is the “server” - my understanding of endpoint_host(?).
My post above mentions only Omnia (ie. server) configuration. I didnt configure client yet (just generate another (client) key-pair to use public client key on server)
Client IP is unknown, I want to have ability to connect from different networks…
Sure, it was not clear to me whether the router is the endpoint or a remote node being the endpoint, considering option route_allowed_ips '1' not making sense when the router is the endpoint since it would route all outbound traffic via the WG tunnel.
I dont need restriction(s) to the vpn users (me), so its easier to read firewall config instead of lots forwardings wan-wg, wg-wan etc. Same approach I am using with openvpn. But I tried also different zone for wg with forwarding, but result was the same.
