Editing `Wireguard.Address` in config.json fails to start

[eeldivad]

i'm using the latest v9.0.0 and when i modify Wireguard.Address then restart the service, it will give an error that it can't bind to the old Address. so it appears to be trying to use the old address stored in the db instead of what i changed it to in config.json. it does however bind the new IP to the wg adapter.

also when i change ACLs.Policies ip range/subnets in config.json and restart the service, it doesn't use the new subnet ranges when generating new client configs and uses the old ones that are still in the database.

[NHAS]

Not being able to change the Wireguard.Address from the config is an untended bug, thank you for finding that!

It's not advised to change the vpn subnet as all of your wireguard peers will continue to have IP addresses that are in the old subnet (as unfortunately there is no way to dynamically change a wireguard address from wireguard itself)

As for the ACL policies changes, there is a warning after first use that indicates that policies and settings will be loaded into the database on first run and ignored after.

I suggest using the management interface, or cli to update your acls.

[NHAS]

I see that the bug you're getting is this:

2025/08/20 09:15:02 could not start web server for "tunnel", err: listen tcp <address>:<port>: bind: cannot assign requested address

Which happens due to the tunnel being set to the ip address being stored in the webserver object.

[eeldivad]

yeh i don't mind using the management interface to make changes but i didn't see the options. i'm not familiar with the CLI but i can try it in the future. i decided to go back down to the older version before clustering was added. it's stable and simple. if there were better docs on how to use the CLI with examples then that would be helpful. thanks!

[NHAS]

Howdy was just noting this as I was just able to replicate it. I am currently working on a new docs site that gives better documentation, unfortunately I just dont have a lot of time.

Definitely agree that using the old version is fine! It may just have bugs that will not be remediated, but it wont have any new ones!

[eeldivad]

hey no worries. i know you're busy and appreciate your continue support of an awesome project! i'll check back again in a few months or so and see how it goes.

[NHAS]

Just adding my own notes.

1. Could take a hash of the remarshalled config struct on load and if it has changed we apply the difference
2. Store the full config, on load generate a diff using jsondiff and apply whats changed, which also helps us on our first steps to gitops compatibility