Since I do not understand correctly how


works, I would be happy if someone could explain to me what I can do more generally than disabling Webrtc in my browser. Is there any possibility to prevent this with firewall rules using iptables?


Instead of blocking the access from the firewall (iptables), it is easier to block it from the browser itself. If you are using Firefox or Iceweasel, you can disable Javascript completely (using NoScript addon, or any similar addon).

If you don't want to disable Javascript, you can disable only WebRTC connections. To do that, enter about:config in your Firefox address bar, confirm that you know what you're doing, and then enter media.peerconnection.enabled in the search bar displayed. When the name appears in the list below, you'll notice that its value is set to true. Double click on it to make it false and that's it! WebRTC is now disabled!

Afterwards, you can visit this demo page and see for yourself that your local and public IP addresses are not leaked any more.

If you're using TorBrowser, you don't need to do anything extra, because the WebRTC setting named media.peerconnection.enabled is set to false by default.

Just for the sake of completeness, I'll mention that there is also an extension for Google Chrome called WebRTC Block.

I should mention that it is hard to detect IP leaks using a firewall that works only on the transport/network layer (like iptables) when the leaking is done by an application. The reason is that every application has a different way of doing it, and there is no global solution to all. The best thing to do is to either stop using the application entirely (and perhaps find an alternative) or to stop the part where the leakage happens (which usually disables some functionality of the application).


I came across the following iptables rule which seems to work according to ipleak.net.

iptables -t raw -I PREROUTING -p udp -m multiport --dports 3478,19302 -j DROP

It only prevents WebRTC with NAT/IPv4. It might not be totally effective, given its destination port driven, an equivalent rule would need to be devised for IPv6, but given the protocol design differences, might not be the same.

  • According to the RFC for a STUN URL's syntax, destination port is arbitrary and is chosen by the adversary. iptables will never suffice so long as non-torified connections are able to egress. – cacahuatl Dec 7 '16 at 7:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.