Why do we need proxies with UDP and what does the WebRTC leak in Antidetect have to do with it?

[chushpan]

How will any anti-fraud system detect IP address substitution even when working through a proxy + VPN (or just a proxy)? Why do we need proxies with UDP support? Why won't Antik (antidetect browser) help with WebRTC checking, even if all services show that everything is fine?

In this article, we will figure out how WebRTC can "give out" your real IP address, why regular proxies often do not solve this problem and how to deal with it.

Proof

What is WebRTC and how does Antifraud systems use it?​

WebRTC is a protocol for transmitting streaming data. It is most often used in JavaScript.

• Anti-fraud systems use WebRTC to detect various characteristics of your system. For example, WebRTC (especially in Chrome) may use the UDP protocol by default, which allows you to make a request directly from the user's real IP address.
• If you use a proxy without UDP support (and most proxies do), WebRTC requests will bypass the proxy and reveal your real IP. Even if all other connections go through the proxy, it is WebRTC traffic that can break through NAT and show your real IP.
• If you are connected via VPN without a proxy, WebRTC will give out the IP address of the VPN. But for anti-fraud systems, this is also a reason to "add" fraud-score points, since they see that you are using a VPN connection instead of a regular provider.
• There are few proxy services on the market that provide full UDP support. We hope that proxy service developers will also read this article and expand the functionality, but so far there are only a few such solutions.

How exactly does WebRTC "leak" your real IP?​

When we visit a website (for example, antifraud.com), the antifraud system loads special JavaScript scripts into the browser. Usually, these scripts are heavily encrypted (obfuscated), so it is extremely difficult to read them with the naked eye.

Detection steps:

1. The site makes a request to its internal server via TCP (a regular fetch request)
2. The anti-fraud system responds to this request and “tells” the browser: “Make another additional request to my STUN server on such-and-such port.” This initiates an additional check.
3. "The browser has no choice but to fulfill this request. And no anti-malware can prevent this, since it is impossible to catch and block all addresses.
4. The browser makes a UDP request - after all, the STUN server needs to be accessed via UDP.
5. Antifraud easily compares your “regular” TCP request (via proxy) and UDP request (directly) within the same session.

• If the IP addresses are different, then you are using a proxy or VPN.
• This way you can determine your real IP (or at least VPN IP).

Example: you can check the operation of this scheme through our test service -
http://172.86.65.208:8080

The algorithm is implemented there in the same way as described above.

What to do?​

First and foremost: The proxy must support UDP. If there is no

UDP support at the proxy level, then neither Antik, nor Router, nor Goodwin (¬‿¬) will be able to “screw” it on for you — it must be there initially. It is also important to understand that UDP support can only be in SOCKS5 (HTTP / HTTPS / SOCKS4 simply does not have it). In addition, not all SOCKS5 proxies work correctly with UDP. You can check SOCKS5 support for UDP using our software (ZloyRouter).

In our group, we also tested many proxy services for UDP support - but only a few actually provide it.

What about VPN?​

VPN (OVPN, PPTP, WireGuard) always supports UDP out of the box, so our test will show:

TCP IP = UDP IP, just like the average user.

This is because VPN and proxy work fundamentally differently and connect differently:

• VPN tunnels all your traffic,
• Proxy (including SOCKS5) works at the application level (in our case, the antidetect browser).

Read about levels here. Our test, as we have already found out, can use the transport layer (UDP), so VPN usually "passes" the test without problems, but the proxy - only if it supports UDP and is connected correctly.

Problems with Chrome when working via SOCKS5​

Even if your proxy correctly supports UDP, and you launch a browser with good SOCKS5, you still won’t be able to pass our test. The reason is that “our favorite” Chrome (and any antidetect browsers based on Chromium) does not support full-fledged operation of WebRTC traffic (UDP, STUN, etc.) through a SOCKS5 proxy.

Chrome and Chromium-based antidetect browsers do not allow WebRTC traffic (UDP, STUN, etc.) through SOCKS5. This is a long-standing "feature" (or limitation) related to the fact that WebRTC by default tries to directly "break through" NAT, bypassing any proxy. In Firefox, these requests are simply blocked.

Conclusion: all Chrome-based antidetect browsers (and most of them) are subject to this problem.

Write in the comments if you are interested in why this happens

How to get around this?​

ZloyRouter

You can overcome the problem by correctly "distributing" SOCKS5. We solve this with the ZloyRouter program. You just insert your SOCKS5 into it. If SOCKS5 really supports UDP, WebRTC traffic will go as it should - through a proxy, and the test will not suspect a trick.

[SOCKS5 (UDP support)] --> [ZloyRouter] --> [Chrome/Antidetect]

1. It's immediately obvious if you have a problem with UDP.
2. If there was a problem, you automatically solve it.

If I block UDP, will it be OK?​

This is certainly better than "leaking" your real IP address. If you encounter a similar WebRTC check somewhere in the "wild", there is a chance that you will pass it.

However, the vast majority of regular users do not have WebRTC blocked, and for them TCP IP = UDP IP. If you have WebRTC/UDP blocked, the anti-fraud system may suspect something is wrong and add additional "fraud points".

Why don't all the "antidetects" show the leak?​

You can check yourself on browserleaks.com/webrtc or similar services and not see real IP leaks. But these services are known to antidetect browsers and their developers:

• They simply replace the necessary data and say: “The problem does not exist.”
• This lulls the user's vigilance.
• In fact, the technique of “penetrating” IP via WebRTC-UDP has been known since 2019, and any anti-fraud system can (and will) use it.

The problem can be solved by correctly forwarding the proxy.

By the way, if our test site does not open in Chrome, it means that proxy providers simply blocked it to hide the fact that they do not support UDP. For example, Astraproxy and IPRoyal did this. They say "we have UDP", but for some reason the test site is unavailable. Draw your own conclusions.

Some antidetect browsers also block our test on purpose, and at the same time "everything is fine with them", but in fact the problem remains.

Summary​

Use good software, subscribe to the group (https://t.me/Zl0yTeam) and don't be discouraged. Good luck to everyone! You can overcome this - you just need to distribute your SOCKS5 correctly - We have solved this problem with our ZloyRouter program. You just insert your SOCKS5 into it and if it supports UDP, then the traffic will go as it should through the proxy and the test will not suspect anything. Firstly, you at least know right away whether you have this problem. Secondly, you automatically solve it if it does.