It could expose credentials if the client is trying to talk to a server like via HTTP POST or whatever that is only reachable by VPN.
There is because at worst you are creating a connection to an attacker TCP port that does not have the information the application will need to use. You can create a session but not to the correct resource. Once that connection is not correct, what will happen? SSH will create a flag, HTTPS will create certificate errors, this becomes no different than ANY OTHER MITM attack vector at that point, which is always a existential threat on public wifi. This is not new.
Yes but only for devices running software VPNs directly on the device.
It wonāt happen if your GL.iNet router does the VPN stuff. At least not until somebody using the DHCP attack within your GL.iNet network.
So we could even say: Using a travel router makes your traveling more safe. 
1 Like
How does the VPN traffic get uncloaked? How does the attacker get between your laptop and your endpoint and hand off the connections any different than they can in ANY OTHER mitm attack, though?
Correct, but such leak can be seen by the VPN network. In this attack it can be seen by someone connected to you local LAN.
1 Like
Here is another way to look at this. Remove the VPN piece for a second.
You have MultiWAN set up on your router.
ISP 1 is 1.1.1.1
ISP 2 is 2.2.2.2
You have a client, 3.3.3.3, trying to connect to your server at 4.4.4.4.
4.4.4.4 allows connections from 1.1.1.1 but not 2.2.2.2
If your client goes out 2.2.2.2 due to load balancing, what happens? No sessions are created, right?
This is what would happen if a server behind the VPN concentrator is tried to access from the connection that is not using the VPN.
Itās actually a MITM attack but it is being performed through adding a route (split-tunneling) from within the LAN side using DHCP Option 121.
What are they going to see? You are describing what would be a highly targeted attack if even a fragment of a network session like a leaked packet will compromise the privacy and integrity. That is spy level stuff and nothing most of us do who are using GL devices are operating at a level than a Russian or Chinese or North Korean or whoever you are hiding from cares.
Again, though, there is nothing to see as no important connections will traverse the non-vpn route. Only attempts to establish a session. Very little useful information for sometime trying to steal facebook credentials or credit card numbers (which are in TLS/HTTPS already). Plus you will get all of the cert errors, just like you would with sslstrip. Like I said, this is not new stuff.
I donāt mean to be dismissive of the threat, but this is what I do for a living and I am a little āpassionateā about security and privacy.
2 Likes
If the attacker is connected with your uplink stream, they canāt read your traffic because the traffic will be forwarded by your travel router to the VPN before it reaches the Starbucks router*. And as I showed at the beginning, the travel router doesnāt care about other routing rules.
So in that case all people connected by the Free Wi-Fi are fuckād, but you are safe.
On the other hand:
If the attacker connected to your network and attacks - then you are not safe anymore.
So conclusion: Letting people inside your network is dangerous.
*) Technically it will reach the router ofc, but it will be encrypted then.
1 Like
ā¦ it means your GL deviceās can be compromised as any other nix-based system (by local attacker) to leak your destined VPN traffic through the other phy interface! And AS LONG AS you are not using an encrypted protocols your traffic will be exposed. By the way since this is a MITM attack, an attacker can then reroute your traffic to the correct gateway to complete the handshake.
As I showed above, the router does not adopt dhcp option 121 - at least not like creating the real routing rule for it. So ā¦ no?
Feel free to simulate it by yourself and share the results!
Agree! An attacker needs to get into your Opal to start the DHCP attack.
At least into your Opalā network. As long as the attacker can send the DHCP answer faster than the Opal, he is good.
Interesting! I might test it later when I get time as I need to rush now! Thanks guys for the discussion!
2 Likes
Always a pleasure, even if I thought we were screaming at each other, haha 
1 Like
Not true! He can perform an old school DHCP starvation attack.
From the researcher blog:
We want to stress that there are ways an attacker who is on the same network as a targeted user might be able to become their DHCP server:
A rogue DHCP server using a DHCP starvation attack against the true DHCP, then responding to new clients. We have achieved this in lab environments and are working on a follow-up blog post.
A rogue DHCP server racing to respond to DHCPDISCOVER broadcasts to abuse DHCP clientsā common behavior where they implement first-offer lease selection.
ARP spoofing to intercept traffic between the true DHCP server and client, then waiting for a client to renew their lease.
1 Like
itās ok by me man!
Yeah, ofc. There are plenty of ways to disturb the regular DHCP. Being the fastest is just the one with the smallest tracks.