This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.
Sounds to me like it totally works even after the tunnel has started.
More like a corrupt traffic cop. There are reasons you might want this kind of functionality, which is why it exists. Normally you can trust the cop (DHCP server) but in this case the cop has decided to send everyone from all streets down to the docks.
Sounds to me like it totally works even after the tunnel has started.
Yeah, it’s like a fake traffic cop basically, sending your (network) traffic down the wrong route
More like a corrupt traffic cop. There are reasons you might want this kind of functionality, which is why it exists. Normally you can trust the cop (DHCP server) but in this case the cop has decided to send everyone from all streets down to the docks.
These types of attacks would likely be implemented via DHCP spoofing / poisoning, unless you’re on a malicious network
I’d think the place most people use VPN is public wifi, unless they are utilizing workplace VPN.