WireGuard interface address 'invalid'

General questions
1

I have been playing with VyOS (rolling, latest snapshot) for a couple of days now. I have a decade plus experience with Linux and *BSD, and until now ran a mixture of pfSense, OPNsense and IPFire on my home edge router. I have annual subscriptions to several VPN providers, including AzireVPN and Mullvad - both of whom provide WireGuard access.

While it was a little alien at first, I very quickly started to love VyOS. It’s so elegantly simple (a bit like pf) and easy to use. A quick glance at ‘show conf’ instantly lets you spot any errors that could be causing an issue. It’s fast, too! About the only thing missing for my own use case at present, for it to completely replace OPNsense, is DNS over TLS or HTTPS (unbound, stubby, dnscrypt-proxy or similar).

I’ve deployed a VyOS instance in VMWare Workstation, with 2 virtual NICs; eth0 acts as ‘WAN’/DHCP (to my ‘real’ router) and eth1 is a VMWare Lan Segment acting as LAN interface for other VMWare client OS’. I got the actual VyOS install and basic config up and running in minutes - nice! Unfortunately I can’t get WireGuard working on it no matter what I try. Would someone please help me unpick this? I did ask on the VyOS subreddit but I’ve not had any solutions yet.

AzireVPN provides me the following config to use on my device:

“DNS”: “91.231.153.2, 2001:67c:15ec:1337::2”,
“Address”: “10.20.17.50/19, 2a07:241:1:4000::1133/64”,
“PublicKey”: “j3Yw1nWiSgz8YAGp95KrvyvUhVLCFZ5msO33KR/A0Dc=”,
“Endpoint”: “uk1.wg.azirevpn.net:51820”

As you can see, the address it wants me to use on my interface is 10.20.17.50/19. This works OK in Linux and BSD directly and using wg-quick. Unfortunately, when I try to set interface wireguard wg0 address 10.20.17.50/19 it just refuses and tells me it’s an invalid value. I did try 10.20.0.0/19 also, and while this works I can’t get any throughput that I can tell.

Even with the interface finally added, my VyOS install itself and all local DHCP clients still report my main ISP address (using curl ipinfo.io) rather than the wg tunnel address. Should my static route be 0.0.0.0/0 or 10.20.0.0/19 - or something else?

Also, how do I add the tunnel’s DNS? Do I use the usual ‘set service dns forwarding listen-on’ and tie it to the wg0 interface?

I did add a firewall rule in OUTSIDE-IN for UDP port 51820 (the default wg port, as used on my config) so it’s not that. Any advice would be really appreciated. The Wiki is unfortunately rather fragmented on this issue, and some of the commands are out of date. The related discussion on Github added some extra potentially usable config (as did a post on this forum) but again I’m having no luck. I can post up my full config if anyone wants to see it, but hopefully someone can spot something obviously wrong in what I posted so far and help me get off and running.

Thanks in advance!

2

Hi,

10.20.17.50/19 is on your side or on the remote side terminated?

3

The address validation issue should be not present anymore with todays nightly build. Let me what side 10.20.17.50/19 is.

4

Thank you! I’ll give it another try when I get chance (possibly tomorrow now). The 10.20.17.50/19 is for the client (my) side.

5

Unfortunately I’m still seeing the validation issue:

vyos@vyos# set interfaces wireguard wg0 address ‘10.20.17.50/19’

Invalid value
Value validation failed
Set failed

[edit]

This is on:

vyos@vyos:~$ show version
Version: VyOS 1.2.0-rolling+201810170747
Built by: autobuild@vyos.net
Built on: Wed 17 Oct 2018 07:47 UTC
Build ID: c241bf79-54a8-4a5a-aa07-d5d803afdbc5

Architecture: x86_64
Boot via: installed image
System type: VMware guest

Hardware vendor: VMware, Inc.
Hardware model: VMware Virtual Platform
Hardware S/N: Unknown
Hardware UUID: Unknown

Copyright: VyOS maintainers and contributors

6

Sounds good, you can just use the update function (add image ) in vyos.

Your config should be something like:
set interfaces wireguard wg01 address ‘10.20.17.50/19’
set interfaces wireguard wg01 port ‘51820’
set interfaces wireguard wg01 peer azirevpn-uk1 endpoint ‘uk1.wg.azirevpn.net:51820’
set interfaces wireguard wg01 peer azirevpn-uk1 pubkey ‘j3Yw1nWiSgz8YAGp95KrvyvUhVLCFZ5msO33KR/A0Dc=’
set interfaces wireguard wg01 peer azirevpn-uk1 allowed-ips

set protocols static interface-route next-hop-interface wg01

All traffic to will be now passed via wg01. If your remote side is correctly setup as well and you don’t block the incoming traffic, you should be fine. If not let me know, I’ll have a look.

PS:
set interfaces wireguard wg01 port ‘51820’

This port can be set to whatever you’d like, it is your local one which is optional as well. When your first packet hists the destination, wireguard on the destination uses the src port you sent in your initial packet, assuming it passes authentication and encryption.

7

You gotta wait for VyOS 1.2.0-rolling+20181018xxx unfortunately, the validation check in the cli had an issue which should be fixed in the nightly release. If you want we can set up a channel in slack, you can set via ip meanwhile too if that helps.

(https://vyos.slack.com)

8

My apologies. I mistook ‘latest nightly’ for the one published this morning, not the upcoming newest one. I’ll grab the image when it’s live tomorrow(?) and give it another go. There’s no rush, it’s only a test VM for me to get used to working with it and evaluate it to replace OPNsense (a great distro, but I prefer CLI).

The AzireVPN config works great on my Linux, BSD and macOS boxes so I’m confident it should work OK once the validation bug is ironed out. Thanks so much for the command tips, I genuinely appreciate it. I’m just starting to get the ‘hang’ of VyOS now and really starting to appreciate its simplicity and elegance. I’m still learning the more advanced stuff though, and hoping that I can get this wg issue ironed out and get on with evaluating it for real world use on my edge router. I can’t stress enough how much I love the thing, it’s just so… ‘me’. Again, thank you for your help. I’ll drop you a reply tomorrow to (hopefully) confirm all is well… or maybe to ask another stupid question, haha!
Cheers.

9

All right, I’ve tested VyOS Community for the validation bug, which has been resolved. You can always reach out if you have an issue or found a bug, we will have a look.

10

Thanks so much. I can add the correct address and get the tunnel up now. Using ‘show interfaces wireguard wg0’ now confirms ongoing handshakes and the usual small amounts of swapped data up and own that entails. So my firewall rules and tunnel/interface setup is good. I still can’t get the router itself nor local LAN clients to communicate via the wg interface though. This is me being pretty newbie at networking, rather than any actual bug or issue now, I’m sure. Could you (or anyone) kindly let me know what I missed?

Starting with the tunnel up and no static routes set by me, show interfaces gives eth0, eth1, lo and wg0. All good. The wg0 interface is handshaking and everything seems OK. So now I do:

set protocols static interface-route 0.0.0.0/0 next-hop-interface wg0

and everything dies. I can ping my ‘real’ (non-virtual) home router at 192.168.1.1. Nothing reaches the actual internet though (i.e. ping 1.0.0.1 fails). I can’t curl ipinfo.io or do anything else outside of the LAN. Issuing ‘show ip route’ gives:

vyos@vyos:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] is directly connected, wg0, 00:00:11
S 0.0.0.0/0 [210/0] via 192.168.1.1, eth0, 02:44:39
C>* 10.20.0.0/19 is directly connected, wg0, 00:29:01
C>* 172.16.0.0/24 is directly connected, eth1, 14:47:10
C>* 192.168.1.0/24 is directly connected, eth0, 02:44:39

But the VyOS router itself and all LAN clients are unable to get to the internet. The firewall is set to allow 51820 UDP, and this is confirmed by the wg0 interface being able to handshake upstream with AzireVPN.

vyos@vyos:~$ show interfaces wireguard wg0
interface: wg0
public key: bprOD5WahhPxhRl8QGWR3NfD9n0K+8NQ7KEXN/Iuw14=
private key: (hidden)
listening port: 51820

peer: j3Yw1nWiSgz8YAGp95KrvyvUhVLCFZ5msO33KR/A0Dc=
endpoint: 185.137.67.60:51820
allowed ips: 0.0.0.0/0
latest handshake: 13 minutes, 59 seconds ago
transfer: 1.59 KiB received, 2.32 KiB sent

It’s just that no other interfaces are able to route through it. What did I miss? I’m pulling out my hair, so I signed up for some online classes related to networking and computer science. I’m not just asking for someone to spoon feed me, I just need to get this working and then understand how, and what went wrong so I know for next time. Thanks so much in advance.

11

I can see the issue already, let me explain it a little more detailed. When you start the wg interface, you have a default route.

S 0.0.0.0/0 [210/0] via 192.168.1.1, eth0, 02:44:39

So, all traffic which is not for any connected networks or the host itself will be forwarded to 192.168.1.1.
Then you change it to the wg interface and it won’t be able to find it’s way out since it becomes the default gateway. All external addresses won’t be reachable anymore, sionce everything goes to wg01 which has no interface to forward the traffic.
I think there is also a little misunderstanding with allowed-ips, I think your goal is that all client traffic which is connected to your vyos, is supposed to be encrypted via wg.
Allowed-ips acts a a type of policy within the wireguard code, so if you would have set it to allowed-ips 10.1.1.0/24 and set the interface route 0.0.0.0/0 to the wg interface, the wg policy already drops your packets if it is not coming from 10.1.1.X.

So either you set a host route for 185.137.67.60, or leave the default route to 192.168.1.1 (which is currently inactive according to your output) and set routes for the destination(s).

12

OK, thanks for that. You’re correct, I’d intended allowed-ips 0.0.0.0/0 to mean all local traffic was sent and encrypted via wg0. AzireVPN’s config files show allowed ips: 0.0.0.0/0 and say that’s what it’s for (inside the wg.conf files used by wg-quick) so I assumed it translated over to VyOS.

I’ve removed my static route and am back to

vyos@vyos:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route

S>* 0.0.0.0/0 [210/0] via 192.168.1.1, eth0, 04:29:59
C>* 10.20.0.0/19 is directly connected, wg0, 02:14:21
C>* 172.16.0.0/24 is directly connected, eth1, 16:32:30
C>* 192.168.1.0/24 is directly connected, eth0, 04:29:59

Without sounding really dumb, I’m autistic (as in diagnosed Asperger’s, not ‘internet self-diagnosed Autistic’) and I’m having a hard time getting my head around this now because I’ve been staring at it for so many days under mistaken pretences. Once I’ve ‘got’ it it’s there forever and I’ll add it to all the other Unix stuff I can do, but atm it’s a case of not seeing the woods for the trees. Would you be kind enough to print the commands I need to enter to get this working now? Don’t worry if it’s too much hassle, I know I’ve already asked you a lot.

I basically have the tunnel up, but with no allowed IPs set (because I’m confused as to what to allow now) and no static routes set. The intention is to have wg up, and sending all local traffic (from the VyOS router itself) as well as all local LAN client traffic (from eth1) through the wg interface. In other words, it becomes a VPN router and all local clients are protected without doing anything.

Info you may need if you’re kind enough to help me out with the required commands:

VyOS interfaces - eth0 (WAN, DHCP), eth1 (LAN, 172.16.0.0/24 with dhcp and dns forwarding), wg0
The wg0 interface uses - endpoint 185.137.67.60:51820 and its address is 10.20.17.50/19

Basically I want LAN clients on 172.16.0.0/24 to be able to connect to VyOS, get a LAN IP, and all their external traffic to go via wg0 rather than out through eth0 to my ISP directly. Anything else is a bonus. Again, my apologies if I’m frustrating you or asking too much. I tend to learn by doing and if there’s nobody to show me how it’s supposed to work in its finished form (so I can reverse-engineer it to ‘how’ it worked) I’m pretty stumped.

13

OK some progress. Default route restored, and after reading the Cryptokey Routing section on the WireGuard website I can indeed leave allowed IPs at 0.0.0.0/ as this only affects the server. That changed back, my tunnel is now up and working. If I issue:

ping 1.0.0.1 interface wg0

I get replies showing that the WireGuard interface is being used.

vyos@vyos:~$ ping 1.0.0.1 interface wg0
PING 1.0.0.1 (1.0.0.1) from 10.20.17.50 wg0: 56(84) bytes of data.
64 bytes from 1.0.0.1: icmp_seq=1 ttl=56 time=23.8 ms
64 bytes from 1.0.0.1: icmp_seq=2 ttl=56 time=27.8 ms
64 bytes from 1.0.0.1: icmp_seq=3 ttl=56 time=25.2 ms
64 bytes from 1.0.0.1: icmp_seq=4 ttl=56 time=23.4 ms
^C
— 1.0.0.1 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 23.407/25.074/27.875/1.750 ms

Great! I’m still reading around to work out how to get the LAN clients routed through it, I imagine I literally need one ‘set protocols static interface-route xx.xx.xx.xx/x next-hop-interface wg0’ to get it working… But I don’t know what to input for it without making things worse. I tried using the wg interface address as per the guide in the Wiki (i.e. 10.20.17.50/19 in this case) but that doesn’t work. If anyone would provide me the final piece of the puzzle I’d be grateful. I’ll keep trying to work it out myself though, in the interim.

14

Hi,

I was more thinking src based routing is what you are looking for, but while I was testing I found a bug (⚓ T918 policy based routing doesn't work). What it basically does is, it changes the default gateway for your interface where your client traffic arrives, while everything else is being as before. That has the advantage that all traffic from your clients will hit the wg interface, while traffic from other interface or if you send traffic locally, is going the default route. I think that was what you have been looking for. If you need the functionality urgently I can post you the manual step you would have to perform, the majority of commands is via cli though but the src activation needs to be done manually until I found the src of the problem in the.
Here is something to read for you in case you are interested how src based routing works.
Simple source policy routing
VyOS User Guide — VyOS 1.3.x (equuleus) documentation

That way you have a pretty lean config which you can expand easily as well.

code.

15

I had some time to build a test config, let me know it works for you.

set interfaces ethernet eth1 policy route ‘TESTS’
set policy route TESTS rule 1000 protocol ‘all’
set policy route TESTS rule 1000 set table ‘111’
set policy route TESTS rule 1000 source address ‘0.0.0.0/0’
set protocols static table 111 interface-route 0.0.0.0/0 next-hop-interface wg01

That will route all traffic on eth1 to wg01. If you need then routes to other interfaces or networks your router handles, you can extend then the policy. (set policy route TESTS rule 1000 …).

Hope it helps.

1 Like
16

At first it still wasn’t working. The wg0 interface was up and ping worked (directly from VyOS with ping 1.0.0.1 interface wg0), but LAN clients still couldn’t connect. Then I remembered… NAT. I deleted outbound-interface eth0 and added outbound-interface wg0 and boom.

vyos-success
vyos-success889×273 40 KB

I had to change the DNS forwarding to point to the VPN server as well, and will look into having that depend on external interface (so, VPN DNS for wg0 and ‘preferred DNS’ for eth0) but that’s all icing on the cake and no rush.

For what it’s worth, I devoured the links you posted on your next-to-last post and have been doing some other reading up about source and policy routing. I also signed up for Khan Academy’s computer science course and a CCNA course to learn more so I can help myself more next time. As I said earlier I honestly wasn’t just looking to be spoon-fed. I like to learn, but you have to start somewhere.

FWIW, you have transformed my early VyOS experience from almost a week of sheer frustration (mostly related to my autism and the way I learn) into something positive, and helped explode my interest in VyOS. I really couldn’t get over this hurdle and was close to giving up. I really hope that’s worth something to you, as I really am grateful. If I can send you a tip to buy beer (btc or something?) or you have a favourite charity I can donate to (I’ll post the screenie here or PM you) by way of thanks, I’ll be more than happy to. Seriously, thank you so much.

1 Like
17

Nice to hear, if you run into issues don’t hesitate to create a ticket or post here. We all started at one point.

18

Thanks again, hagbard. Just FYI tonight’s rolling release (201810211757) fails to initialise the interfaces on boot, with ‘Warning, can’t initialise wg0 or wg1; wireguard module missing’ (to paraphrase). No biggie I just booted the earlier one and deleted the image (I’m learning); but in case you hadn’t seen it I thought you’d want to know. Thanks again and have a great evening.

19

Thanks, I have to check on that.
Will be fixed in the next rolling, the kernel module hasn’t been built and wasn’t installed.

1 Like
20

Sorry to be a bugbear, hagbard, but in case you weren’t aware there has been no wg module in any of the rolling/nightly releases ever since - including the latest.