Cisco routers restricting Bitorrent protocol

[tetard27]

Hi,

Since few weeks one major ISP in france has decided to restrict the Bitorrent protocol via new cisco routers it's called traffic shaping

The result is a download speed of 0.1ko/sec whatever the torrent, we've tried encryption but it doesn't work.

http://en.wikipedia.org/wiki/Traffic_shaping

Is there a way to bypass this via utorrent or is it planned in a next release ?

Thanks

[boo]

have you tried to use µTorrents encryption?

[tetard27]

Yes the result is the same, I've tried forced as well

[boo]

have you tried to use µTorrets HTTP proxy function and also turned of DHT?

[Ultima]

From the sound of it, they're blocking unknown traffic... Have you disabled legacy incoming connections?

[tetard27]

Yes I've tried all the utorrent options.

Here is how it works

http://www.cisco.com/cdc_content_elements/flash/csc/cisco_FINAL_no-loop.html

[Ultima]

Nothing we can do about it then =T

[MageMinds]

My ISP juste started to do the same, probably with the same device and nothing could be done, I've tried everything ... They do not throttle only the unknown traffic, if they do so they would throttle VPN connections too, but they don't. Actually, you can VPN to a open network and make torrenting by tunnelling through.

As for the HTTP proxy, all the BitTorrent trafic would have to get through the proxy. I haven't tried the proxy though, because I don't know any proxy server to do that. I'm ready to pay like 10$ a month to get a proxy that would allow me to use BitTorrent unrestricted and unlimitted while staying with my existing provider. Actually, I'll change cable provider, I'll take a small company that use the cable network, so I get the same package but 10$ less, that's where the 10$ come from...

Let me know if there's proxy out there that pass the BitTorrent through, I can't make a direct connection to an other peer and other peers can't make a direct connection to me, if so I get filtered and stuck with 3 KB/s upload.

[Switeck]

I had previously said that putting the encrypted traffic on the same port as the unencrypted traffic was short-sighted. If 1 unencrypted packet is sent to you, that port can be throttled hard.

[kurahashi]

IF only uTorrent encryption is well implemented and the uTorrent client is well configured then there should be no practical way to enforce the traffic shaping.

The things should be take care of:

- of course, forced protocol encryption without allowing legacy connection is a must

- all the subprotocols which are AFAIK not encrypted like DHT or PEX. Turn them off.

- the number of connections. The easiest way to catch sight of torrent-using is to count the number of the connections used by the client. This is somehow tricky though, because sometimes you can generate many connections by other ways - for example keeping many websites open in your browser. Remedy: try to decrease your number of connections, even greatly to the very low numbers. Normally this would hurt your torrent performance, but in this case you have nothing to lose, don't you?

- incoming connections. Statistical home user doesn't run any servers and his firewall doesn't allow any incoming connections except... yes, p2p only. Remedy: turn your firewall on AND go proxy for communication with tracker. The last one is tricky again: because if you won't go proxy the incoming connections attempts will still occur (they will be rejected though). On the other hand, extremally sneaky providers can monitor the proxy for the communications with the tracker... As with decreasing number of connections, usually this kind of configuration is not advised and normally it would hurt your bt performance.

- communication with tracker. Unfortunatelly is open and easy to detect. The malicious ISP can configure their network that if it find out a user communicting with any bt tracker they will shape any not recognized network connections (which will be usually p2p). Solution: DON'T use trackers! Try using DHT and/or PEX instead. Remember: after downloading torrent don't run it. You have to edit the torrent first, removing all the trackers. Only then you can start it.

[MageMinds]

I heard that those Cisco are able to partially decrypt the P2P header just enough to identify them as BitTorrent protocol. I found a solution though... Get a VPN connection, search google for Public VPN, there's company out there that want to secure your communications when you're in a HotSpot, like HotSpotVPN.com. There's also free service, but enumerating them here would be shooting myself in the foot, since their servers are already 100% loaded and it's hard to get a connection, sorry guy, google is your friend.

Using the VPN, I can upload full speed, but I find my download rather slow, but at least, it's faster than the throttling my ISP is doing.

[edit]: Just found a VPN provider that officially allow P2P www.findnot.com they're not free, but all free service are overloaded already.

MageMinds

[kurahashi]

I've heard that those Cisco are able to partially decrypt the P2P header just enough to identify them as BitTorrent protocol

If this is really true that only means the encryption is a failure.

[Ultima]

@MageMinds: Eh? How do suppose it could partially decrypt something? The packets are encrypted at once, so there's no way to decrypt it "partially" -- it's all or nothing. Just decrypting one packet would require a relatively large amount of time, even though the encryption scheme used (RC4) isn't the strongest available.

[tetard27]

I hope someone will find a trick to bypass this because I'm afraid that that kind of equipments will be more and more developed

[Ultima]

What is there to bypass? They most likely block unknown traffic, and µTorrent can't masquerade the traffic to look like known traffic.

[Switeck]

Even with protocol encryption set to forced and firewalled, I still see LOTS of incoming hits on my µTorrent port.

These are likely identifiable as "BitTorrent"...due to faulty clients not even trying to encrypt and too stupid to know you're firewalled.

[Ultima]

Is that how it works? I always thought there was some kind of normal communication before the actual BitTorrent handshake? By my logic, if you see incoming hits, they're nothing more than that normal communication, and as long as you don't respond, your client and the other peers won't perform some BitTorrent handshake, and thus it's not identifiable. That's how I see Protocol Encryption working in the first place =T

[kurahashi]

Even with protocol encryption set to forced and firewalled, I still see LOTS of incoming hits on my µTorrent port

That's why you should try to connect with the tracker through the proxy (of course DHT/PEX off too). Incoming peers will try to connect proxy server, not you. The result is the same as being firewalled, except the fact you will have no incoming BT connections (if you are firewalled you will have them - they will be only rejected by the firewall)

[µser]

At least your being packet shaped, my ISP just cuts my bandwidth FOR ANY UPLOADING for any period of time. I get nerfed down to 60 kbps up (384 rated, ~300 normal). Any uploading period, takes about 12 hours before it blocks me, but i'm on the third day with nerfed service.

Worst part is they are forcing me to remain behind a hardware firewall. Never get a wireless ISP.

Derailing rant /off