TunnelCrack VPN Flaw

Does OpenWrt need a patch for this?

Utilizing a firewall-based kill-switch and DNS encryption should solve the problem, so OpenWrt-specific patches are not required.

Hmm so it would be safe to assume:

A typical zone forwarding like:

lan -> wireguard
wireguard -> (Input drop or reject, output accept, forward reject)

Would be more secure for tunnelcrack?

And this one is more unsafe?

lan -> wireguard
lan -> wan
wireguard -> (Input drop or reject, output accept, forward reject)

Or would the default software vpn kill switch also be suffice enough to block it on the second snippet? I always felt this type of setup felt more unsafe :yum:, I have seen both setups being used for kill switches.

This will use the wan when vpn is down for some reason.

We cannot know that, as the default software vpn kill switch may vary and usually doesn't support forwarding.

1 Like

For a maliciously configured LAN subnet?

Perhaps I misunderstand the purpose of the switch.

VPN on router:

Sounds feasible; but only assuming the user is not the device's administrator. Otherwise, since the user's LAN is configured by the administrator (i.e. you), I don't see how the LocalNet attack affects OpenWrt.

:spiral_notepad: the upstream/ISP demarcation still be maliciously configured; but proper route configuration (e.g. create a default route on a separate table and assign LAN to it by rule), and as noted firewalling (e.g. only allowing LAN-to-VPN) mitigates that.

VPN on downstream client (OpenWrt-related?):

Also, as with most networking on OpenWrt, the administrator configures the routes, LAN subnets, WiFi, etc. - so not sure how this affects OpenWrt.

Fix a DNS leak - before the VPN connects?

  • What if the DNS server IP (and PKI) is spoofed too?
  • Using the endpoint IP of the VPN instead of hostname could mitigate this

The scenario of interest is connecting to an untrusted network router (R1) with an OpenWrt travel router (R2) running a VPN client.

LocalNet attack
I don't think the kill switch on R2 solves the problem. The kill switch is usually setup to block lan traffic forwarding to wan. It does not block traffic originating from R2. Otherwise you can't connect to your VPN server.

The TunnelCrack paper has more detail. They offer some countermeasures, some of which have been mentioned.
6.1.1 Disable local traffic.
6.1.2 Filtering excluded local IPs. (only allow RFC1918 to be excluded from VPN as local network)
If you are on an untrusted network, disabling local traffic exclusion seems like a good practice even if you just do it manually, assuming you remember. If it is a dedicated travel router, you probably never need local access.

Server IP attack
(on R1), 'We use iptable rules to redirect VPN traffic to the real IP address of the VPN server and we detect VPN traffic based on the destination IP address and the port. This iptable rule also ensures that responses from the real VPN server are forwarded to the client.'

6.2.1 Policy-based routing. A defense against ServerIP
attacks is policy-based routing, where routing is not purely
based on the destination IP address, but also on other factors
such as the application generating the traffic.
6.2.2 Verifying the server IP address. (after connection)
6.2.3 Authenticated DNS. (DoT, DoH, or DNSSEC)
5.6 'We noticed that the custom clients of most VPN providers are not vulnerable to the ServerIP attacks. This is because they do not use DNS to find the VPN server’s IP address'
It mentions somewhere that connecting to VPN server via IP avoids the DNS problem.

Some Other comments:
It does not mention OpenWrt anywhere in the paper. The Linux OpenVPN client is mentioned.
A possible OpenWrt patch could be for VPN Clients that allow excluding local networks to restrict it to the excluded networks to RFC1918 addresses. They mention some other VPN clients that do this,
'Windscribe and ExpressVPN only allow local network access when using RFC1918 private IP addresses.'
Interesting note from Mullvad, 'The Mullvad VPN app does not use DNS in any way to obtain VPN server IPs. Our app fetches the list of VPN server IPs from our own API.' But, don't they need DNS to lookup their API host?

1 Like

Your statements imply all VPN software sets up routes and rules automatically on OpenWrt. I only know of OpenVPN as doing this (as it relates to the common VPNs discussed on OpenWrt forums) - but I've never used it on OpenWrt to know if it's the same behavior.

That would be correct, unless they are IPs too.

To be clear,: "connecting to VPN server via IP avoids ServerIP Attacks" - correct me if I'm wrong. The ServerIP Attacks require a malicious DNS result to be provided for the VPN server - with an IP the attacker actually desires to exploit.

Let's use an possible example of a hypothetical OpenWrt user:

Alice has a Wireguard WARP connection setup on her OpenWrt - let's just say her closest Data Center is in Bob City (using cybersecurity example names here :wink: ). Mallory Home Internet, Allice's ISP - want's to see if they can intercept the DNS requests to Cloudflare. They're just doing some experimentation. So they do the following things.

  • They configure their ISPs DNS server to provide and A record for engage.cloudflareclient.com - to answer with
  • They intercept all DNS requests i.e. 53/udp (:spiral_notepad: this is why I add they could simply intercept the DoT and DoH too and the PKI)
  • The VPN port is redirected in Mallory's core network to the real engage.cloudflareclient.com
  • :boom: The DNS requests to are now seen outside the tunnel :open_mouth:
  • They can redirect these to the real :boom: they can keep giving for all subsequent requests for anything (but they would have to somehow know what to redirect to if this is to accomplish anything)

Agreed. The ?.?.? wasn't meant to be questioning, I just didn't have the section # handy. Updated my earlier post to include it.

For your Alice in VPNland story. Yes, good point. They also mention that in the paper.
4.2.2 'Our attack can also be abused to (try to) intercept all traffic to the DNS server set by the VPN client. The adversary can then intercept DNS requests and spoof replies, enabling the interception of most IP-based traffic'

That was not my intent. I started with a question. You can consider my 2nd post to have an implied, 'for vulnerable clients...' I don't know if there are any, but I suspect if OpenVPN has a feature to exclude the local network from VPN, then it could be vulnerable if it doesn't restrict excluded networks to RFC1918.

1 Like


Yes, since it doesn't provide a firewall-based kill-switch.

I think this attack requires a tampered upstream router, e.g. a compromised hotspot.

It can create a local subnet route for a specific target IP overriding the the default VPN route.

You can reach the VPN endpoint by IP and allow only DNS over VPN, or split DNS traffic for OpenWrt and LAN clients, or just use DoH/DoT for everything, etc.