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 
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 
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: 1234peer: 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)
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 
All traffic is routed through WG, no DNS leakage. Without any wurther PostUp / PostDown commands, or special postrouting/MASQ on server side firewall… 
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
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 
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
The cherry-picked commit fixed it. In a few secs, I will push it to the nightly branch and will be part of Turris OS 3.11.
1 Like
Hi,
I followed several setups before coming across the wiki page you created.
I did a very similiar setup with 2 differences:
- I didn’t create a seperate firewall zone but used the lan-zone instead:
that way you don’t need anymore forwards as you firewall-wise anyway bridge lan- and wg0-zone
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan wg0'
option masq '1'
- I don’t use the following forward:
config forwarding
option src 'wan'
option dest 'wg'
I think this is a mistake derived from someone trying the setup without looking into what he/she actually did (as it can be found in several forums) - noone would want to have a forwarding from WAN to internal interface. And it works without that forward.
A question that arose:
Is there any manual setup of routes (in openvpn achived via pushing routes to the client) needed if connecting two TO? I’d like to create a complete site2site-setup - so that any PC behind TO1 can reach TO2 and any PC behind TO2 and vice versa. → solved!
edit - question 2:
Wireguard status-site doesn’t seem to work, I will allways get the following scheme:
It is a bug in TOS3.x and its relevant LuCI package. It does work in TOS4.x
I would recommend VPN policy based routing possible? - SW help - Turris forum