You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If two or more VPN locations use the same IP network address, a conflict arises if the corresponding tunnels are connected simultaneously
To Reproduce
Steps to reproduce the behavior:
Create two VPN locations
Assign (unique) gateway IP addresses but on the same network
Connect a Defguard client to both locations at the same time (nothing stops you from doing so)
In the best case only 1 tunnel will work. Conflicts may also arise in the assignment of IP addresses to the clients
Expected behavior/enhancement
Defguard considers every VPN location as a completely independent realm, where no coordination in the assignment of IP addresses is attempted, and under the silent assumption that locations using the same VPN IP netmask are not to be connected to simultaneously. This can be a valid use case, but the situation where several VPN locations could be sharing the same VPN IP network are valid (and very useful), too.
For instance, I frequently use Wireguard to set up a pattern manually where:
VPN servers (gateways) at different locations use IP addresses from the same network
client define a single Wireguard interface, with all the gateways as peers on this single interface. The "allowedIPs" field is used to define static routing
In this way, the client can access several parts of a distributed infrastructure by using a single wireguard interface, which simplifies management and reduces the number of addresses/networks to handle.
This use case could be easily supported by Defguard if:
we would detect when the same VPN IP network is entered for different locations
we would then allow an option to "group" those locations together and treat them as a single tunnel connecting every client to different endpoint.
The client would then have an option to connect to the whole "location group" with a single action (bringing up a single wireguard interface), entering MFA information only once, and so on.
I hope my description is clear enough; please feel free to contact me in case additional information is needed (also on matrix: @dbutti:matrix.neaweb.ch)
Version information
Defguard Core version: v0.10.0
Defguard Gateway version: v0.10.0
The text was updated successfully, but these errors were encountered:
@dbutti of course we could incorporate that check rules in our solution, but I think it's a wider problem. As an administrator you are responsible for managing your networks, and even if defguard/gateways do not interfere with their networks, still as and admin you could have the same networks as defguard has configured internally, and the same problem would arise.
I think admins know what they are doing and know their network enough - but if not, this is just one of may potencial network problems and am not convinced that we should put effort into only one edge-case.
Describe the bug
If two or more VPN locations use the same IP network address, a conflict arises if the corresponding tunnels are connected simultaneously
To Reproduce
Steps to reproduce the behavior:
Expected behavior/enhancement
Defguard considers every VPN location as a completely independent realm, where no coordination in the assignment of IP addresses is attempted, and under the silent assumption that locations using the same VPN IP netmask are not to be connected to simultaneously. This can be a valid use case, but the situation where several VPN locations could be sharing the same VPN IP network are valid (and very useful), too.
For instance, I frequently use Wireguard to set up a pattern manually where:
In this way, the client can access several parts of a distributed infrastructure by using a single wireguard interface, which simplifies management and reduces the number of addresses/networks to handle.
This use case could be easily supported by Defguard if:
I hope my description is clear enough; please feel free to contact me in case additional information is needed (also on matrix: @dbutti:matrix.neaweb.ch)
Version information
The text was updated successfully, but these errors were encountered: