ffries
August 17, 2020, 6:38pm
6
On client the route is not set properly:
sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.0.10.2/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] nft -f /dev/fd/63
root@x230:/home/mario# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 192.168.9.1 0.0.0.0 UG 600 0 0 wlp3s0
10.90.103.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr2
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 virbr2
192.168.9.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
ffries
August 17, 2020, 6:48pm
7
It's finally working, there was error in a private key. Sorry for the error. I can ping both sides.
I will post my complete settings when finished.
On Debian side, the default route via wg0 is not set:
route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 192.168.9.1 0.0.0.0 UG 600 0 0 wlp3s0
10.90.103.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr2
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 virbr2
192.168.9.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
But all traffic is going through wg0 as per seen using tcpdump -u wg0 on both sides of the tunnel.
Very stranger. I would expect to see the route.
ffries
August 17, 2020, 7:09pm
8
Wireguard speed on the GliNet B1300 is good (too bad it lacks AES-NI):
iperf3 -c 10.0.10.1
Connecting to host 10.0.10.1, port 5201
[ 5] local 10.0.10.2 port 35924 connected to 10.0.10.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 42.4 MBytes 355 Mbits/sec 0 975 KBytes
[ 5] 1.00-2.00 sec 40.5 MBytes 340 Mbits/sec 0 975 KBytes
[ 5] 2.00-3.00 sec 41.6 MBytes 349 Mbits/sec 0 975 KBytes
[ 5] 3.00-4.00 sec 40.5 MBytes 340 Mbits/sec 0 975 KBytes
[ 5] 4.00-5.00 sec 41.6 MBytes 349 Mbits/sec 0 975 KBytes
[ 5] 5.00-6.00 sec 41.6 MBytes 349 Mbits/sec 0 975 KBytes
[ 5] 6.00-7.00 sec 41.7 MBytes 350 Mbits/sec 0 975 KBytes
[ 5] 7.00-8.00 sec 40.2 MBytes 337 Mbits/sec 0 975 KBytes
[ 5] 8.00-9.00 sec 41.5 MBytes 348 Mbits/sec 0 975 KBytes
[ 5] 9.00-10.00 sec 41.3 MBytes 346 Mbits/sec 0 975 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 413 MBytes 346 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 411 MBytes 344 Mbits/sec receiver
ffries
August 17, 2020, 7:15pm
9
Using /32 addresses offers additionnal security because wireless clients will not be able to ping each other. Using /24 solved the issue of route on client, but wireless clients will be able to ping each other.
Here are my settings with /24 subnet:
OpenWRT Server:
config interface 'wg0'
option proto 'wireguard'
list addresses '10.0.10.1/24'
option private_key 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
option listen_port '51820'
config wireguard_wg0
option public_key 'BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB'
option preshared_key 'EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE'
option description 'client'
option persistent_keepalive '25'
list allowed_ips '10.0.10.2/24'
Firewall rule:
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan wg0'
...
config rule
option dest_port '51820'
option name 'Allow-Wireguard'
option target 'ACCEPT'
list proto 'udp'
option dest '*'
option src '*'
Debian roadwarrior client:
cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
Address = 10.0.10.2/24
[Peer]
PublicKey = DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
PresharedKey = EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
Endpoint = 192.168.1.75:51820
AllowedIPs = 0.0.0.0/0
The security of the WG mainly relies on cryptography.
Allowed IPs are required to use non-overlapping subnets for proper routing, which is easiest to achieve with the shortest address.
ffries
August 18, 2020, 12:46am
11
Still I am having a problem, I cannot add a second client.
config wireguard_wg0
option public_key ''
option preshared_key ''
option description 'samsunggalaxy'
option persistent_keepalive '25'
list allowed_ips '10.0.10.3/24'
Finaly I have been using /24 range.
Now it does not start saying that I don't have a private key.
ffries
August 18, 2020, 8:39am
12
I have to admit I am quite lost.
Do I need a new private key on server side for each new client?
Does it mean each new client should be on a seperate subnet?
All this is quite heavy for roadwarrior settings.
Please help.
No to both questions.
Check out examples in the docs.
ffries
August 18, 2020, 9:01am
14
I will double check my configuration because I see nothing wrong and I don't undestand why /dev/wg0 is not running with two clients.
config interface 'wg0'
option proto 'wireguard'
list addresses '10.0.10.1/24'
option private_key ''
option listen_port '51820'
config wireguard_wg0
option public_key ''
option preshared_key ''
option description 'x230'
option persistent_keepalive '25'
list allowed_ips '10.0.10.2/24'
config wireguard_wg0
option public_key ''
option preshared_key ''
option description 'samsunggalaxy'
option persistent_keepalive '25'
list allowed_ips '10.0.10.3/24'
krazeh
August 18, 2020, 9:04am
15
Change the AllowedIPs for your peers to /32 addresses.
1 Like
Please, read the replies carefully:
ffries
August 18, 2020, 9:09am
17
Thanks. What do you mean with shortest address?
I moved to /32 addressing and LuCi still displays:
Configuration : interface does not have a public key!
So I switched back to /24 addressing.
Besides all information on the WIKI is with /24 subnet:
https://openwrt.org/docs/guide-user/services/vpn/wireguard/start
Roadwarrior example of the WIFI does not allow more than 1 client to connect, so it is wrong:
https://openwrt.org/docs/guide-user/network/tunneling_interface_protocols#static_addressing_of_wireguard_tunnel
non-overlapping subnets are different subnets.
Can you elborate more and give examples in the case of two roadwarriors clients.
/32
for IPv4 and /128
for IPv6.
Peer subnets can overlap, but allowed IPs cannot.
It is a subnet for the interface, not for allowed IPs.
1 Like
krazeh
August 18, 2020, 9:22am
19
Does it have a public key?
1 Like
ffries
August 18, 2020, 9:25am
20
Yes, it does. I am posting my config again. Configuration works with one roadwarrior client. When a second roadwarrior client is configured, it does not work and complains for public key. Here it is:
config interface 'wg0'
option proto 'wireguard'
list addresses '10.0.10.1/24'
option private_key ''
option listen_port '51820'
config wireguard_wg0
option public_key ''
option preshared_key ''
option description 'x230'
option persistent_keepalive '25'
list allowed_ips '10.0.10.2'
config wireguard_wg0
option public_key ''
option preshared_key ''
option description 'samsunggalaxy'
option persistent_keepalive '25'
list allowed_ips '10.0.10.3'
Now if I uncomment second roadwarrior conf, it work;
#config wireguard_wg0
# option public_key ''
# option preshared_key ''
# option description 'samsunggalaxy'
# option persistent_keepalive '25'
# list allowed_ips '10.0.10.3'
I find Wireguard extremely picky with configuration.
krazeh
August 18, 2020, 9:27am
21
And the public key for each peer is different? Taken from the setup on the client device?
1 Like
ffries
August 18, 2020, 9:29am
22
The public key was generated by Android application with QR-code. Let me regenerate by hand, give some minutes. This could be it.
The Android app does not use nice fonts and I cannot distinguish L from l from I.
ffries
August 18, 2020, 9:36am
23
I regenerated client keys (private, public and PSK).
Now it returns:
wg show
interface: wg0
public key: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
private key: (hidden)
listening port: 51820
peer: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
preshared key: (hidden)
allowed ips: 10.0.10.2/32, 10.0.10.3/32
persistent keepalive: every 25 seconds
So it is not complaining for public key any longer!
Still I cannot connect with Debian client.
krazeh
August 18, 2020, 9:42am
24
That would appear to indicate that the same public key is being used for both peers, unless you've changed one of the peer configs to put both 10.0.10.2/32 and 10.0.10.3/32 in the AllowedIPs?
1 Like
ffries
August 18, 2020, 9:43am
25
All public and private keys are different, I just double-checked.