New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 19 users

Issue metadata

Status: Fixed
Email to this user bounced
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Sign in to add a comment

When using a proxy, WebRTC leaks unproxied IP address even with multiple routes disabled

Reported by, Jun 5 2015

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Disable WebRTC multiple routes (
2. Get Tor running on
3. Start Chrome with `--proxy-enabled="socks5://"`
4. Visit
5. Note that both your Tor IP address and your actual unproxied Internet IP address are revealed

What is the expected behavior?
Your actual unproxied Internet IP address should not be revealed.

What went wrong?
Disabling WebRTC multiple routes was partially successful: my LAN IP address is now hidden on when it wasn't before, but my unproxied public IP address is still visible.

It appears that WebRTC now uses a single route that bypasses the chosen proxy server.

Did this work before? N/A 

Chrome version: 43.0.2357.81  Channel: stable
OS Version: Xubuntu 14.04
Flash Version: Shockwave Flash 17.0 r0

Label Cr-Blink-Webrtc-Network should probably be added to this bug, as this is similar to  bug 333752  and  bug 457492 , and they use that label.

This probably shouldn't be merged with either of those bugs since those bugs eventually specifically limit themselves to the solution of allowing someone to disable WebRTC multiple routes, which doesn't work here.
Labels: -Cr-Internals-Network Cr-Blink-Webrtc-Network
Status: Assigned
erlercw@ - do you see the same behavior with the current beta (44.0.2403.30) or Canary builds?

Assigning to guoweis@ since he currently owns  bug 457492 .
from what I saw, Tor doesn't support UDP. I suspect the leak of the public address is due to the UDP pinging turn/stun. We might need to disable UDP altogether to prevent this leak.
"from what I saw, Tor doesn't support UDP."

Yes, but totally irrelevant.

When a proxy is specified, it means that all communications must go through the proxy. If the proxy cannot support UDP, UDP should fail; UDP should not try to go around the proxy.

When using a SOCKS proxy, Chromium usually doesn't try to do DNS lookups (via UDP or TCP) or QUIC.

Comment 4 by, Jun 12 2015

Labels: Cr-Privacy
any chance to provide a wireshark capture?

Comment 6 by, Jun 17 2015

Yup on the latest Canary the multiple_routes_enabled workaround no longer works...Impressive that the problem has been made worse.
#3 is right. The fact Tor doesn't do UDP is not really related.

Here is what I see. Chrome's parameter "--proxy-server" only handles http/https. In my test, Chrome just let udp traffic through when specifying tor as proxy.

If my understanding is correct, the "leak" here is caused by not passing UDP through Tor (such that it could either drop it or support it as tcp). The leak could be caused by any UDP based protocol from chrome, not just webrtc. So this needs to be solved at a lower level instead.
#6, could you clarify your scenario? Are you saying this option doesn't work anymore even without Tor?
QUIC will fall back to SYPD if proxy is detected, hence avoiding the ip leak issue there. It seems that we should do similar - i.e. if proxy is specified AND the multiple_routes is disabled, only http route will be used.

Comment 10 by, Jun 19 2015

I have created a master bug There are another 4 bugs underneath to track this issue.
Labels: WebrtcTriaged
Here is the design I'm leaning toward to.

The assumption I'm making here is that Tor users will have proxy configured manually (instead of using PAC or auto-detected). If we detect that's the case AND another to-be-invented property set (similar to multiple_routes), we'll stop UDP altogether.

Could anyone comment whether this will or not work for your scenario?

Comment 13 by, Jul 10 2015

I think that assuming manual proxy configuration would be incorrect. A scenario where PAC makes sense includes:

* Initial setup of multiple browsers to not leak IP addresses when using proxies
* Desire to connect to only some websites using proxy
* Desire to avoid using proxy with any other websites
* The websites you want to proxy might change in the future

For example, you want dozens of your employees to be able to conduct research on competitors through Tor. You don't want to burden the Tor network with your employees' Facebook browsing and YouTube watching. Competitors might come and go, so you need a way to update the list of hostnames to dozens of computers. IP address leaks are a bad thing.

For a non-Tor example, you want your VPN service to be able to offer your customers access to geographically-restricted videos. You don't want to burden your network with people playing WoW or downloading downloading ISOs. Restrictive video sites might come and go or change CDN hostnames, so you need a way to easily update the list of hostnames on every browser on a user's computer. IP address leaks are a bad thing.
If I read your comment correctly, I think you're making a case that PAC has some use cases that manual configuration won't achieve. I totally agree with that. However, what I'm not getting is how this fits into the picture of webrtc, particularly in the context of stopping IP leak. The proposal I had in #12 doesn't change how other traffic works. It only changes webrtc's traffic.

Are you saying that you have scenarios where PAC is used and you still want WebRTC's traffic to go through the proxy from PAC? PAC could be configured in a way that TURN gets a proxy A, STUN gets proxy B, remote candidate 1 gets proxy C, candidate #2 gets proxy D.. etc. Even if we could implement this, I have a hard time to imagine how people will validate the proxy selection.

Maybe I have misunderstood your point. Could you clarify?
Another question I have. 

Would you rather to have 

1) a check box "Honor my proxy" which, when manually checked, stops UDP and uses any kind of proxy setting in chrome, 

2) or a default which will only honor the proxy if the proxy is manually configured (i.e. UDP will still be used if proxy is configured through PAC nor auto detect). Note that the manually configured proxy might not always be the routable path to TURN though.

Comment 16 Deleted

Comment 17 by, Jul 20 2015

I misread comment 15, and I found another example of PAC file usage, so I'll try again.

Comment 14:

Yes, there are some cases where you want WebRTC's traffic to go through the proxy from PAC. Here are two examples.

On jailbroken iOS, you can't set a system-wide SOCKS proxy using the iOS settings. One workaround is to use a PAC file (see to specify one proxy for all traffic.

With Internet Explorer's proxy settings (which are used as system proxy settings by Firefox and Chrome quite frequently, and so are used to configure all browsers in one place), SOCKS4a and SOCKS5 proxies can't be entered (it only allows for SOCKS4). The workaround is to use PAC files (see


Comment 15:

I'd prefer the first option.

Most importantly, if I know what I'm doing and I use a PAC file, the second option denies me the ability to stop WebRTC's UDP usage, since the second option doesn't do it and there's no way to shut off WebRTC except on Android.

Also, the second option will defeat the obvious expectations of users and system administrators, and it will do so when security is on the line. People will expect, if they specify in a PAC file that all traffic is carried over one proxy, that this won't allow traffic to leak outside of the proxy.
Thanks for the feedback. We have some discussions among ourselves and will most likely go with option #1 at this point -- let users decide when  to stop UDP

Comment 19 by, Jul 29 2015

#1 seems like the simplest short-term solution. 

We may need to eventually have some extension for the PAC file that indicates when WebRTC traffic should traverse the proxy, or perhaps just follow the decision made for the HTTP origin.

Comment 20 by Deleted ...@, Aug 15 2015

I would also consider #1 to be a good enough solution, just let us decide whenever we persist to honoring our proxy settings. 

45.0.2454.37 is still leaking the public IP and thus rending using a socks proxy for privacy reasons totally useless. I am truly surprised that it takes this long to implement a fix. 

Is this to be expected anytime soon?

Comment 21 by Deleted ...@, Oct 19 2015

47.0.2526.16 and still leaking? This must be a joke! Come on google, wtf? 

Comment 22 by Deleted ...@, Oct 20 2015

is this ever going to get fixed??
Yes. Expect a new version of the WebRTC Network Limiter Extension soon.

Comment 24 by, Nov 17 2015

FYI, a new version of the WebRTC Network Limiter Extension has been published that addresses this issue:

Details at!topic/discuss-webrtc/bMOsMFx7PFc.
Status: Fixed
This has been fixed in M47 with the new mode from Network Limiter extension which disallows UDP.

Sign in to add a comment