Google Voice via STUN = magical phenomenon!

E

EnthusiastXYZ

Limp Gawd
Joined
Jun 26, 2020
Messages
221
For this analysis, outgoing router ports were restricted to TCP ports 80, 443, and UDP port 51820. On my rooted Android phone (without a SIM card), capturing wlan0 via TCPDump showed that all connections from local phone IP connected to VPN IP via port UDP port 51820 (Wireguard). That included Google Voice calls. Capturing tun0 packets showed that Google Voice used STUN UDP ports 19302-19305 and most packets passed through tun0 virtual adapter IP, but to initiate a connection (when either making a call or receiving a call), Google Voice connected my local phone's IP to Google STUN server IP directly without passing through VPN tun0 adapter IP using STUN ports 19302-19305. Router logs for the same time frame did not show any devices attempting to use ports other than Wireguard VPN UDP port 51820 and wlan0 dump for the same time frame also showed that only port 51820 was in use. How was this possible? I could understand how an app could bypass a VPN app, especially a Google app on an Android phone, but why were there no wlan0 dump and router log indicators that there was a direct connection from device's local IP to a Google Voice STUN server?

I decided to take it to the next level and used reverse USB tethering (unencrypted) VPN tunnel for phone's internet connection, which was further tunneled via PC's encrypted VPN connection. I blocked my Android phone's MAC in router. Once again, Google Voice used VPN (reverse USB tethering tunnel) for most of packets, but to initiate a connection, it bypassed reverse USB tethering tunnel and connected (or attempted to connect) to Google STUN servers directly via phone's WiFi local IP! Once again, router logs showed nothing for the same time frame... Disabling WiFi on the phone resulted in Google Voice not being able to make or receive any calls, even though it was connected to the internet via reverse USB tethering and PC's VPN tunnel.

STUN could've created its own socket for a connection, but that would've shown up in router logs or in wlan0 dumps, wouldn't it?
 
Google Voice is the one and only app that registers as "root" in logs (for IP 216.239.36.145). All other apps in logs register with their app names.
 
All VPN apps I tried - from proprietary to open source, regardless of protocol, had the same exact STUN connection leak issue with Google Voice. I started 24 hour TCP dump and spent as much time as I could using my phone. Google Voice ended up being the one and only app that bypass virtual tun0 VPN tunnel adapter. However, I couldn't figure out from verbose TCP dumps whether that STUN connection was simply dropped because Google Voice couldn't have used WiFi when device MAC was blocked. On top of that I blocked all ports for the same device and that didn't affect anything.

What other logs could I look at to see what the phone did during those direct STUN connections?
 
Thanks! None of it explains why it bypasses a VPN on Android phones and whether it actually does bypass it because in my case, outgoing ports 19302-19305 are blocked and router logs never indicate that there is an attempt to connect over those ports. VPN app developers say that those connections are simply dropped. Additionally, i.google.com domain is blocked everywhere. Google Voice also uses lens.i.google.com domain. It doesn't bypass a VPN connection on Windows machines.
 
I launched Netstat during a Google Voice call and it showed that domain resolution for 216.239.36.145 also bypassed my VPN and connected directly from my local IP. Logs from VPN apps showed me "NetworkThrowable" error and something related to XOR.
 
Last edited:
From when I remember from the shorts days I worked on Stun/ICE stack, stun's on the client side will create is own ports and is trying a lot of different strategies to find your public IP address and open a channel for UDP and there is a bit of a farwest in trying to predict how it will play out.

Maybe is available tools is more limited in windows than on your Linux and that why he fail in windows but succeed a little more over Linux.
 
I am trying to see if I can write an IPTable rule that disables UDP Port 19302-19305 for WLAN0-only and blocks IP for 216.239.36.145 for WLAN0-only.
 
IPTables rules didn't help, but something is funky - the data leak is exists only when using Tun0 interface. Tun0 interface is supposed to show only Tun0, but it shows local IP for that STUN connection. WLAN0 interface does not show it at all. WLAN0 interface shows a 100% constant connection to VPN server...
 
modi123 said:
Seems a lot of the 'why' is outlined here.. 'webRTC' connections and what not.

https://security.stackexchange.com/a/138257
Click to expand...

Yeah, but on Windows, WebRTC leaks have been defeated a long time ago. The same goes for Android, except for Google Voice. I prefer to use BrowserLeaks.com to test browser leaks. BrowserLeaks.com uses Google STUN servers to test for WebRTC leak. My Android browser (Bromite) doesn't show any leaks and AdGuard AdBlocker additionally disables WebRTC in other apps, except for Google Voice.
 
modi123 said:
It's not a leak it's an intentional use of WebRTC.

Example of the long route to stop webrtc on all your browsers.

https://www.vpnmentor.com/blog/disable-webrtc-in-seconds/
Click to expand...

It is a private data leak and WebRTC doesn't leak my local and/or public IP via any browsers that run Windows and/or Android. Google Voice doesn't leak public/private IP info when running via browsers on Windows either, but it does so when running as an app on Android. I can use Google Voice via Android browser (Bromite), in which case there is no leak either, but it is very impractical and incoming calls do not go through when Google Voice is used via an Android browser.
 
I was able to resolve this with Netfilter IPTables by simply blocking local IP for TUN interface. Now all Google Voice traffic over TUN uses TUN-only IP.
 
You must log in or register to reply here.
Back
Top