NHAS
Unable to set device to fixed IP (overwrite), unstable branch
We'd really like to use wag. It looks like a perfect concept for our purposes. So I have compiled and tested the latest code from "unstable". Due to downstream firewalls and their rules, we sometimes have to assign fixed IP addresses to devices. However, this is not possible when creating a new device or user in wag. The error message "no device with that IP" always appears. This seems like a bug.
Another question by the way: Is there a tool or something that allows you to view and edit the stored data (etcd)? This could also be a way to edit IPs afterwards. Forgive my ignorance, I have no idea how to connect to ETCD. Thanks in advance.
Hi there!
Due to downstream firewalls and their rules, we sometimes have to assign fixed IP addresses to devices. However, this is not possible when creating a new device or user in wag. The error message "no device with that IP" always appears. This seems like a bug.
I am going to assume you're using the "overwrite" field. Effectively that field is there to allow you to set an existing devices public key on registration. Not to set the IP of the device on creation, I hadnt even thought of that as something people would want, so Im going to mark this as an enhancement!
You very much can edit etcd manually, its just a bit of a pain. I'll write up some instructions here if you want to attempt it. I wont have an ETA on getting this implemented as Im still slowly slowly grinding away at UI stuff, which isnt my favorite thing in the world.
Grab the latest etcdctl release from there: https://github.com/etcd-io/etcd/releases
Then you can do common operations with etcdctl, as everything is encoded with json you can edit this by hand. But just be warned if you break the entry wag may get sad. It also wont pick up the ip address change immediately (as its not currently designed to do that) , so you may have to restart wag.
Example:
etcdctl --endpoint unix:///tmp/tmp/wag.etcd.<RANDOM PART> get --prefix "devices-"
Etcdctl docs: https://etcd.io/docs/v3.4/dev-guide/interacting_v3/
Happy hunting!
Thanks for taking this as an enhancement. Such a feature would means a lot of reduced workload for us.
I am going to assume you're using the "overwrite" field.
Yes, you were right.
I'll write up some instructions
Thanks very much. Your instructions worked and I was able to change an IP. This really helps a lot.
Im still slowly slowly grinding away at UI stuff, which isnt my favorite thing in the world
I can really understand that! But your UI was the strongest argument for us to use wag. So, please keep up the good work. As soon as the new version of wag is out, we will use it in production.
Thanks for the good work.
I would temper that with, I have made a large number of changes with the most recent pushes on unstable (over 200 commits at this point).
It is quite likely things will be broken on first use. So just be careful haha! Your kind words have given me a bit more motivation to get this done!
I've added this on the new client UI branch. If you want to test it out that'd be great, however the config file is very different to the 8.0.0 branch and is definitely not ready for production, so be warned.
The one caveat I have is I will have to update this to limit what ip addresses can specify otherwise there is a big risk of denial of service. For example if a malicious admin adds the server ip, or a dns ip address as a peer leading to a router being inserted into the routing table effectively killing your server.
Sorry for the late reply. I was very busy bringing faulty core switches back under control. Thanks for the great work and the new features. I compiled the code and made some quick tests. Setting IPs seems working so far, but they are not limited to range of the wireguard network. I will do more tests this and next week and will report back.
Thanks for a great piece of software really fitting our needs!
Howdy. No stress.
I haven't limited it to the VPN network intentionally specifically as I didn't know what your requirements were.
As I mentioned it's a bit of a hazard but I wanted to get feedback before making a decision.
If it's acceptable for you to have it limited to the VPN network that sounds good to me
If it's acceptable for you to have it limited to the VPN network that sounds good to me
Yes, it is. Example: If the wg interface is set to 192.168.1.1/24 it would be perfectly fine to only allow addresses from 192.168.1.2 to 192.168.1.254 .
Thanks for implementing this feature and the great work. Did some tests now. Seems ok, just some small issues: -IP can be set to the IP of the wireguard interface. -If you have a mask of e.g. /24 you can set an IP ending with .1 or .255 . Don't know if this is intended.
Howdy thanks for giving it a test.
Being able to set it to the wag server address is a mistake.
But all the rest is fine.
Since wireguard doesn't support broadcast traffic, we can use a subnets whole range!
I'll give that a patch in the next little while.