Allowed ip's and specific network routing.

[tetricky]

I would like to create configs that restrict access to specified networks (targets) but allow for other routes for client machines to happen local to those machines (ie internet access occurs locally, routing to clients on the VPN to allow ssh over the local wireguard network).

I am far from a wireguard expert, but my understanding is that this can be achieved using "AllowedIPs"

So my hope/expectation is that if I create a VPN, with an endpoint only on the local wireguard VPN subnet (or the the newtork itself - eg. xxx.xxx.xxx.xxx/24 ?) that I can create configs where the AllowedIPs are just for the valid endpoints.

I don't get that, I only ever seem to get "AllowedIPs = 0.0.0.0/0" which then means that I have to alter the configs to provide the network separation that I require for the targets.

Am I misunderstanding what is happening, missing a way to do this, or just plain operating on a complete lack of understanding? Any suggestions how to achieve this, with a minimum of manual alteration of the generated configs would be much appreciated.

[vijaygill]

@tetricky - sorry I am trying to get my head around this requirement. Please correct me if I am wrong...
You want a Group of Peers which can access some (private) machines (targets) via VPN but keep rest of their traffic direct (e.g. internet etc).
And this requires AllowedIPs to be editable.
If so, please open an issue and I will try to work on it tonight or ASAP.
I will try to make this setting available at Peer-Group and Peer level.

But if I have misunderstood your requirement, please let me know.

[tetricky]

I believe you have understood my requirement correctly.

Example use case. I have my desktop, I want to access the internet, and my local network, as normal. I then want to be able to VPN to my servers remotely on the VPN network to perform admin tasks over ssh, etc. While the desktop continues to route internet and other local LAN traffic, over my local network and internet connection.

What I expect to happen: I create a Target, which is the subnet of my VPN network. I create a peer group, which is the computers/server that I want to be able to connect together. I do not include the whole network (0.0.0.0/0), only the VPN subnet. Creating configs for this group should then have "AllowedIPs" set as the VPN subnet. In fact it allows all routes (0.0.0.0/0)

Ultimately it would be good to be able to generate configs for each peer that reflects the peer groups (and their endpoints) that they belong to, including more then one, and a potentially different routing pattern (AllowedIP's) for each peer depending on the peer groups they belong to.

I am unsure what might be possible, and how to achieve that...but ideally it would not involve manual editing of the configs.

I shall create this as a n issue.

[vijaygill]

I believe you have understood my requirement correctly.

Example use case. I have my desktop, I want to access the internet, and my local network, as normal. I then want to be able to VPN to my servers remotely on the VPN network to perform admin tasks over ssh, etc. While the desktop continues to route internet and other local LAN traffic, over my local network and internet connection.

What I expect to happen: I create a Target, which is the subnet of my VPN network. I create a peer group, which is the computers/server that I want to be able to connect together. I do not include the whole network (0.0.0.0/0), only the VPN subnet. Creating configs for this group should then have "AllowedIPs" set as the VPN subnet. In fact it allows all routes (0.0.0.0/0)

Ultimately it would be good to be able to generate configs for each peer that reflects the peer groups (and their endpoints) that they belong to, including more then one, and a potentially different routing pattern (AllowedIP's) for each peer depending on the peer groups they belong to.

I am unsure what might be possible, and how to achieve that...but ideally it would not involve manual editing of the configs.

I shall create this as a n issue.

Cool! I will work on it ASAP. It's been a while since I added something useful to this project :)

[tetricky]

If you were looking for things to do....

I don't know if it's possible (in terms of coding logic, and where things hook into), but it would be handy to be able to have multiple server configurations. That way it would be possible to generate configs for all use cases (including multiple wireguard interfaces for different networks and needs). So one could have a Internet VPN server, a network for managing cloud servers, and also a 'WORKGROUP' for shared services. All managed by the one server generating the appropriate configs.

Currently this use case would have to be met by multiple wg-ui-plus instances. I think. It might be useful, because different 'server' configs might have different DNS and subnet range settings.

It might get a bit complicated, and it's certainly not a 'requirement'...perhaps outside the intended use case.

[vijaygill]

I had thought of that too, but then I decided not implement it (and thus making it a code management hell) and go along with the idea of one instance-per-network/server.

Also I was thinking about your initial requirement, do we need to have "AllowedIPs" as a text field? Can we not use the IP's of the targets as allowed IPs for a given peer? This way, I can concatenate all the IP addresses/network addresses of all the targets a peer can access and have those in its AllowedIP setting (comma separated like AllowedIPs = 192.168.5.0/24,192.168.2.0/24,192.168.3.0/24).

This way we make it less prone to PEBCAK issues.

[tetricky]

...yes. Totally agree. I meant allowing AllowedIPs through setting the Targets, and using the Target IP addresses to automatically set the "AllowedIPs" in the config.

I agree about keeping it simple and having one server config per instance....that makes most sense for most use cases, and keeps the code tight and less complex...which is a major bonus. Most people are not going to need multiple servers.

[vijaygill]

I will implement this feature this evening. I will publish a "dev" image for your testing purpose and if all goes well, a proper release.
Thanks!

[vijaygill]

Issue #179 implemented. Any further discussion on this requirement can be posted in the issue itself.