IP Ranges for device registrations

[Reis-A]

I am a little confused about the way the ip addresses are assigned in the configuration files...

in version 8.1 it looked like the addresses were picked randomly
now in 9.1.6 it is systematic from the lowest ip up... (which I think is great)

will there will be eventually an ip overlap with old registered devices?
great would be if i could assign an ip range... but maybe not since it is now pure upwards assignement form 192.168.6.1 up 192.168.6.255 for instance

A sentence in the readme about this wouldnt hurt.

[NHAS]

The algorithm to select next up isn't just incrementing upwards.

We keep track of deleted (abandoned) device addresses as well.

So while there are fresh ip addresses to use that don't exceed the cidr we use those incrementally. When wag runs out it'll choose from abandoned addresses.

Otherwise it errors saying the range is full.

As for being able to allocate up address ranges to devices, that is outside the scope of what wag is designed to do and would break some of the assumptions it has to make in order to function.

[Reis-A]

Thanks that helps a lot to understand the way it works.
However with my upgrade from 8.1 i ran into troubles.
I had wag-vpn setup with oidc keycloak and put on the wag-vpn server a nginx on port443 in front of it as a proxy.
That nginx proxy served as a proxy to the tunnel and to various internal webserves, keycloak on a different server among them.

Now with the upgrade to 9.6 (or 9.0 as you like), everything changed quit a bit with the tunnel weblogin ,right.
The callback url of the oidc includes the port... so if i want the port to be invisible to the endusers, i am forced to put the tunnel on port 443. well then i cannot put the nginx on port 443 anymore... so i wanted to resolve that with an additional ip in the vpn network... but since there is no ip reservation in wag-vpn i would need a second interface in the vpn network... and then i run into routing problems...
if there is an easier solution i am all open for that. Maybe i did everything too complicated :D

[NHAS]

At this point as wag natively supports ACME for TLS I would just use the wag tunnel directly rather than trying to shim a reverse proxy in there, even though that is supported its not well supported.

[Reis-A]

thank you this comment helped me... i serve now keycloak from a different nginx machine in the vpn network. i dont need to run nginx on the wag-vpn machine necessarily.
having multiple nginx can still be a good thing though, - to control access to various services with wag rules based on MFA authenticated or unauthtenticated (required for keycloak)

[NHAS]

Not quite sure what you mean by multiple nginx instances controlling access to things.

Wag will only do network level restriction, so if it can hit an nginx instance that is hosting multiple subdomains then your user will be able to access those applications.

Glad it helped tho!

[Reis-A]

nginx 1 could serve keycloak, other public websites, without authentication
nginx 2 can serve (legacy) services that are not compatible with oidc / MFA and then are granted access to after vpn mit with mfa
and a dnsmasq service on the wag-vpn server that guides the traffic :)
Just a use case...