Wireguard setup

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’

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.

Thank you, I will try this after a couple of minutes (cant break inet connection right now). When I disable this option, will be client able to reach all lan devices, without much fiddling or adding manual routes?

also because luci interface is broken for Turris OS packages (datatypes.lua).

I can see, I updated it 2 months ago. It’s part of Turris OS 3.10.6 and newer. Would you please tell me more about it? So, I’d be able to reproduce it and fix it. I think even screenshot with the traceback from LuCI would be fine for me. I tested it and it was working and I tried it now, but I didn’t find the broken interface for LuCI as you said.

If you’d find any bugs or something broken, please let us know immediately, so we can look at it because if I would know about it earlier, I could fix it for Turris OS 3.11.

I have 3.10.8, and I hit the same problem mentioned somewhere in the forum.

/usr/lib/lua/luci/cbi/datatypes.lua

doesnt contain base64 type etc. (https://github.com/openwrt/luci/commit/94d6b7b70d858c33ec0feabd22733c05c9fb529f).

I can see created peers in luci, but I cant create new (button) through the Luci.

root@Doma:~# opkg list | grep wiregu
kmod-wireguard - 4.4.161+0.0.20180918-1-0a333a8e606ab056173befac424900d2-1
luci-app-wireguard - git-18.145.30016-526a876-1
luci-proto-wireguard - git-18.145.30016-526a876-1
wireguard - 0.0.20180918-1
wireguard-tools - 0.0.20180918-1

LuCI 526a8767846acbe57c521912b35feb4d97354db6 branch (git-18.145.30016-526a876) / OpenWrt omnia 15.05 r47055

Actually do not disable but specify the local subnet rather than routing all list allowed_ips '0.0.0.0/0'

WG LuCI is available via Network -> Interfaces, but the version on TO is not in sync with upstream OpenWRT

Actually, I tried specify lan subnet (10.0.5.x) there, but it was even worse, I wasnt be able access router (after restart) and only schnapps rollback saves this situation :frowning:

I already had feeling, that problems is maybe in combinations

option route_allowed_ips ‘1’
list allowed_ips ‘0.0.0.0/0’
list allowed_ips ‘::/0’

but ofc I need vpn user to be able reach lan, and in the same I need to have fully operating router :slight_smile:

Now I see that the ::/0 is not needed, as I dont configured v6 yet, but I can hardly imagine this could be the trouble (as troubles are (also) in ipv4)

Yep, thats which I was aware of, and configured peers (actually also iface) through UCI… Its always better use uci or conf files edit than Luci anyway…

WG LuCI is available via Network -> Interfaces, but the version on TO is not in sync with upstream OpenWRT

I disagree, because based on your so many requests, I have updated it to that latest version from OpenWRT and because arguing with you takes so many time for me and others, I decided to look at it and I’m constantly checking for new version of Wireguard, so I can update it and push it to the nightly branch.

You can see it here:

Anyway, I was able to reproduce it. Thanks for letting me know!

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

So, I have cherry-picked the commit as you mention and if it would fix it, I’ll try to include it in Turris OS 3.11.

1 Like

With

option route_allowed_ips ‘0’

I am able ran wg

root@Doma:~# wg show
interface: wg0
public key: xxxxx
private key: (hidden)
listening port: 1234

peer: yyyyy
allowed ips: 0.0.0.0/0
persistent keepalive: every 25 seconds

and router internet connection on router works fine. Still for some reason, I cant get sucesfull handshake with client though. Is this correct?

root@Doma:~# telnet localhost 1234
telnet: can’t connect to remote host (127.0.0.1): Connection refused

what is the output on the router cli of wg show?

Where are the clients located, e.g. outside router lan/wan? Which WG apps are running on the clients?

even when nothing happened (just freshed ifup):

wg0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.10.1 P-t-P:10.0.10.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MTU:1420 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:22 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

:frowning:

Its located in my post above.

I am trying from both lan and wan Win clients (TunSafe), with config (only difference is LAN and WAN ip/port)

PrivateKey = private clients key
DNS = 10.0.10.1
Address = 10.0.10.2/32
[Peer]
PublicKey = Public omnia key
AllowedIPs = 0.0.0.0/0
Endpoint = public omnia ip:xxxx
PersistentKeepalive = 25

If I recall correctly from the WG mailing list the WG developer dimisssed TunSafe for being closed source and due to implementation issues. Not sure if that view changed since then.

If you can try a linux client or Android client (wg beta app in the store) or the TestFlight client for iOS. I am not familiar with WG clients on WIN systems.

That you cannot connect a lan client could be an indicator for a firewall issue. Is Masquerading (plus perhaps also MSS clamping) enabled for the WG zone?

I was able to make sucesfull handshake with Linux client.

However, with config above doesnt work:

  • all trafic through VPN (for example with ip.iol.cz I have still clients IP)
  • I cant access LAN resources

What works:

  • I can access router itself

I was able to make sucesfull handshake with Linux client.

However, with config below doesnt work:

  • all trafic through VPN (for example with ip.iol.cz I have still clients IP)
  • I cant access LAN resources

What works:

  • I can access router itself

CLIENT:

[Interface]
PrivateKey = private client key
DNS = 10.0.10.1
Address = 10.0.10.3/32

[Peer]
PublicKey = public server key
AllowedIPs = 0.0.0.0/0
Endpoint = public server IP:port
PersistentKeepalive = 25

SERVER

config interface ‘wg0’
option proto ‘wireguard’
option private_key ‘private server key’
option listen_port ‘public port’
list addresses ‘10.0.10.1/24’

config wireguard_wg0
	option public_key 'public client key
	option route_allowed_ips '0'
	list allowed_ips '10.0.10.2/32'
	option persistent_keepalive '25'
	option description 'Jirka'

SERVER FIREWALL

config zone
option name ‘wg’
list network ‘wg0’
option input ‘ACCEPT’
option output ‘ACCEPT’
option forward ‘ACCEPT’
option masq ‘1’

config forwarding
	option src 'wg'
	option dest 'wan'

config forwarding
	option src 'wan'
	option dest 'wg'

config forwarding
	option src 'lan'
	option dest 'wg'

config forwarding
	option src 'wg'
	option dest 'lan'

config forwarding
	option src 'lan'
	option dest 'wan'

My understanding is that the WG endpoint (server) is not propagating routes to other peers (clients) but that the peers need to be configured (Route Allowed IPs) the routes that can/should be accessed via the tunnel, which is a different concept compared to OVPN.

https://docs.gl-inet.com/en/2/app/wireguard/

Also linux clients have to have IPv4 packet forwarding enabled in the kernel (net.ipv4.ip_forward). Perhaps also net.ipv4.conf.all.proxy_arp

I leave

option route_allowed_ips '1'
	list allowed_ips '10.0.10.2/32'

on server side, and when I finally managed connection from TunSafe client @ Windows, it seems

AllowedIPs = 0.0.0.0/0

on client side does the work right :slight_smile: All traffic is routed through WG, no DNS leakage. Without any wurther PostUp / PostDown commands, or special postrouting/MASQ on server side firewall… :+1:The same seems to be working also for Linux client.

Performance looks VERY good, in full thoroughput (30/30 Mbit) my CPU in Omnia is in percents… Its very different from ssh/rsync/sftp solutions. Now I understand the fuzz about it :slight_smile:

It even looks, like also devices on LAN are reachable! Hmm. Dont see much difference from yesterday, but it seems to be working all out of the box :hushed:

Now the only downside of wireguard for me is lack of:

  • support Android 2.3.6, 4.0, and 4.4,
  • support LibreElec
  • official Windows client
    - support in sslh

When I will have some time, I will wrote article to the Turris user documentation, I think this is really usefull and wg deserves that (after all Turris team efforts to keep this package up to date), especially, when the step-by-step docs (related to TurrisOS) are not so easy to find.

P.S.:
Does anyone experience also errors in runtime?:

wg0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.10.1 P-t-P:10.0.10.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MTU:1420 Metric:1
RX packets:54512 errors:30 dropped:0 overruns:0 frame:30
TX packets:63661 errors:4 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:45990896 (43.8 MiB) TX bytes:53491784 (51.0 MiB)

3 posts were split to a new topic: How to create page in community documentation

That won’t happen, sslh is TCP, and Wireguard is UDP only.

good point, thank you!

I created Wireguard Wiki page

3 Likes