NHAS
commented
1 year ago Unfortunately this is quite hard to fix, the way wag works is that it constantly monitors the real world endpoint (ip & port) of the device and uses that its primary identity metric.
The reason for this is it prevents an attacker who has cloned the wireguard configuration from a device from being able to successfully "step in" on a clients session. I.e if a client authorises, the attacker with the same private key cannot start sending traffic to internal secure VPN resources.
I have been asked for a feature that would keep an authorisation cookie in the web browser that would allow people to either refresh the page without having to re-enter credentials or to have a constant websocket connection that continually refreshes authorisation.
However Im not sure how well this would work for say a mobile device and it also become a concern that an attacker would be able to step in on a connection, as there would be no real in-web-browser way of identifying a good user roam, vs an attacker assuming the connection.
I'll have a think about it. But unfortunately I think this may be marked as "cant fix" as detecting and responding to these types of events are already painful with wireguard, and making the distinction between friend and foe is virtually not possible.
paulb-smartit
If a user is using 3rd party wifi/4G etc. when they roam between points and get a new connection they will be seen as a new connection. This will cause a need to revisit the OTP page to reauth. I have a few users who see this as an issue.
Is there any thought you have toward maintaining authentication between roaming changes?