Wireguard setup

[anon50890781]

kmod-wireguard 4.4.119+0.0.20171017-…4-0
wireguard 0.0.20171017-1
wireguard-tools 0.0.20171017-1

wg-quick: not found (seems that it has not been compiled)

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

config interface 'wg_vpn'
 option address '192.168.112.12/24'
 option listen_port '49999'
 option proto 'wireguard'
 option ifname 'wg01'
 option _orig_ifname 'wg01'
 option _orig_bridge 'false'
 option private_key '<SERVERS_PRIV_KEY_HERE>'

But then how/where to configure the [Peer] section? And which location are the keys supposed to be stored?

[lampra]

You need to create a wireguard .conf file

cat ~/wireguard/wg0.conf
[Interface]
PrivateKey = ???
ListenPort = 58389

[Peer]
PublicKey = ???=
AllowedIPs = xxx.xxx.xxx.xxx/xx
Endpoint = example.com:58389
PersistentKeepalive = 25

[anon50890781]

@lampra Thanks for the feedback/input!

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?

[lampra]

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

Look at the wg-quick script for more

[anon50890781]

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)

[lampra]

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.

[anon50890781]

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.

[einar]

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'

[anon50890781]

@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?

[einar]

Wondering how you figured this out as there does not seem to be proper documentation either on TO or upstream at OpenWRT/LEDGE

I took inspiration from the docs, the package source, and discussions such as this one: https://forum.lede-project.org/t/solved-setup-wireguard-connecting-two-networks/4215

So, after all it is working via uci. Did you try something like PostUp, PostDown etc?

It can’t be done, it’s wg-quick specific. I have no idea if LEDE/OpenWRT has triggers for interfaces being brought up or down.

Does it matter where key files are located and how did you get them written into network file as opposed to wgX.conf?

Sadly, the keys need to be written inside the config as far as I can see. I didn’t look much into the scripts parsing this, though.

Do you have a practical way to quickly start/stop a wg interface/tunnel considering the absence of wg-quick?

Once configured, ifup wg0 and ifdown wg0. They will do the Right Thing ™.

EDIT: This of course doesn’t include extra steps if you want to do a LAN-to-LAN setup (but those are true for all VPNs, not just wireguard).

[anon50890781]

read that

LEDE thread

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.

It can’t be done, it’s wg-quick specific

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.

Sadly, the keys need to be written inside the config as far as I can see. I didn’t look much into the scripts parsing this, though.

Did you

umask 077
wg genkey | tee privatekey | wg pubkey > publickey

and then

cat privatekey and cat publickey?

Once configured, ifup wg0 and ifdown wg0. They will do the Right Thing

Yes, right that ought to do it, execept again that wg-quick actions like PostUp/PostDown would require another script.

[cynerd]

Maybe have to see whether it can be compiled from source on a Debian machine and get it working with full capabilities on TO.

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.

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.

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 https://doc.turris.cz/doc/en/howto/turris_os_build or https://gitlab.labs.nic.cz/turris/myrepo/tree/master). 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.

[lampra]

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!!!

[Jirka]

I tried to follow https://casept.github.io/post/wireguard-server-on-openwrt-router, as it is most recent article found, and also because luci interface is broken for Turris OS packages (datatypes.lua).

But for some reason, when I configured both server/peer parts on Omnia, I lost my internet connectivity on router

I have OpenVPN ono iface 10.0.8.x, tried add wg to the 10.0.10.x

firewall (I dont think is relevant)

> config zone
> 	option name 'lan'
> 	list network 'lan'
> 	list network 'vpn0'
> 	list network 'wg0'
> 	list network 'wifi'
> 	option input 'ACCEPT'
> 	option output 'ACCEPT'
> 	option forward 'ACCEPT'
 
> config redirect
> 	option name 'Router Wireguard xxxxx->1234'
> 	option target 'DNAT'
> 	option src '*'
> 	option proto 'udp'
> 	option src_dport 'xxxxx'
> 	option dest_port '1234' 

Network:

> config interface 'loopback'
> 	option ifname 'lo'
> 	option proto 'static'
> 	option ipaddr '127.0.0.1'
> 	option netmask '255.0.0.0'
> 
> config globals 'globals'
> 
> config interface 'wan'
> 	option ifname 'eth1'
> 	option proto 'static'
> 	option ipaddr 'public IP'
> 	option netmask '255.255.255.252'
> 	option gateway 'public IP'
> 	option peerdns '1'
> 	option dns 'DNSs'
> 
> config interface 'wan6'
> 	option ifname '@wan'
> 	option proto 'dhcpv6'
> 	option reqaddress 'force'
> 	option reqprefix '63'
> 	option noserverunicast '1'
> 
> config interface 'lan'
> 	option ifname 'eth0 eth2'
> 	option force_link '1'
> 	option type 'bridge'
> 	option proto 'static'
> 	option netmask '255.255.255.0'
> 	option ipaddr '10.0.5.1'
> 	option ip6assign '64'
> 
> config interface 'wifi'
> 	option proto 'static'
> 	option ipaddr '10.0.6.1'
> 	option netmask '255.255.255.0'
> 	option delegate '0'
> 
> config interface 'wifi_guest'
> 	option proto 'static'
> 	option ipaddr '10.0.7.1'
> 	option netmask '255.255.255.0'
> 	option delegate '0'
> 
> config interface 'vpn0'
> 	option ifname 'tun0'
> 	option proto 'static'
> 	option ipaddr '10.0.8.1'
> 	option netmask '255.255.255.0'
> 	option ip6assign '64'
> 
> config switch
> 	option name 'switch0'
> 	option reset '1'
> 	option enable_vlan '1'
> 
> config switch_vlan
> 	option device 'switch0'
> 	option vlan '1'
> 	option ports '0 1 2 3 5'
> 
> config switch_vlan
> 	option device 'switch0'
> 	option vlan '2'
> 	option ports '4 6'
> 
> config interface 'wg0'
> 	option proto 'wireguard'
> 	option private_key 'private server key'
> 	option listen_port '1234'
> 	list addresses '10.0.10.1/24'
> 
> config wireguard_wg0
> 	option public_key 'public client key'
> 	option route_allowed_ips '1'
> 	list allowed_ips '0.0.0.0/0'
> 	list allowed_ips '::/0'
> 	option persistent_keepalive '25'
> 	option description 'Jirka'

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?

[anon50890781]

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'

[Jirka]

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…

[einar]

Why are you using the same network zone as VPN and LAN? I think they should be different (well, at least that’s how I did it).

@anon50890781: you only need an endpoint on one side, wg can handle roaming.

[anon50890781]

The router (Omnia) is the “server” - my understanding of endpoint_host(?).

Yes that understanding is correct, although WG language does not specify server/client, only nodes.

In this case remove option route_allowed_ips '1’ or set it to option route_allowed_ips ‘0’

[anon50890781]

you only need an endpoint on one side, wg can handle roaming.

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.

[Jirka]

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.