uTorrent port forwarding blocked

[kadaj 0]

Hello,

 

It's been a cat and mouse game between my .edu's admin and I. They've been blocking each port that I've forwarded for uTorrent. Any suggestions on what is allowing them to monitor what is happening here? They certainly know it's torrenting but it seems they don't have enough proof to just ban network access in itself, which leads me to believe the data is masked but the operations are obvious? 

 

Thanks

[Staff 9764]

Hello,

 

it's unclear, can you please elaborate? Real origin and destination ports are not visible to your system administrators and above all not blockable: since the ports are forwarded remotely on our servers, your network administrators are impotent to interfere with them. All they can see is traffic to/from one single port (the VPN server port your OpenVPN connects to: 53, 80, 443 or 2018) and one single IP address (the entry-IP address of the VPN server your OpenVPN connects to). What they can try to do is study your bandwidth pattern. BitTorrent traffic can have an identifiable up/down pattern if your data exchange pertains exclusively to a torrent client (but it's not a proof of anything, of course).

 

Also, please make sure that your computer is really connected to a VPN server and that you do NOT forward (this is very important) ports on your router (there's an exception to this: when OpenVPN runs on the router itself).

 

Kind regards

[kadaj 0]

This is why I find it weird. I'm connected indeed; tested dns leaking and watching traffic via WireShark and ESET Firewall. For the port, I forward both TCP and UDP packets. I'm under the impression one of these is causing a leak. I have no router installed and I am directly connected to my EDU's port. The admin is indeed able to verify the port that I have forwarded and blocks it accordingly. That is, every time I change the port used by uTorrent - the admin blocks all connections to my IP on that port. I'm trying to figure out how this is possible, as even the packets themselves are addressed to the "internal" IP, and of course data is communicated between the VPN and myself. What could allow the admin to identify the specific port forwarded to the uTorrent client?

 

Thanks

[Staff 9764]

This is why I find it weird. I'm connected indeed; tested dns leaking and watching traffic via WireShark and ESET Firewall. For the port, I forward both TCP and UDP packets. I'm under the impression one of these is causing a leak. I have no router installed and I am directly connected to my EDU's port. The admin is indeed able to verify the port that I have forwarded and blocks it accordingly.

 

Hello,

 

this is possible only if your system is not tunneling traffic (for example if your system is not connected to the VPN). Another option is that your torrent client is forced to bind to your physical network interface, in which case it can bypass the tunnel.

 

 

That is, every time I change the port used by uTorrent - the admin blocks all connections to my IP on that port.

 

 

If your system were tunneling properly, it would not matter which inbound ports your system administrator blocks, they are NOT your college/corporate/office/ISP network IP address ports. In this case a port is an abstraction to designate with two bytes in a packet header an end-point of a process or task in a system. When you remotely forward a port, it means that you instruct our servers to forward packets from the server exit-IP:port to your VPN IP:port. Your physical network card IP ports are never involved in the process, they are totally different end-points (with some approximation, imagine them as a completely separate "set of ports"). On your physical network card IP address, there's only one random port used as an end-point of OpenVPN. All the traffic in your physical network card flows from/to one single port to/from one single port. Only after the incoming packets are inside your system, the underlying packets headers and payloads are decrypted, and that's when the "real end-points" (i.e. the "set of ports" of the tun adapter, the physical network card used by OpenVPN) are revealed so that they can uniquely identify a process in your system. Analogously outgoing packets are encrypted BEFORE they transit through your physical network cards and encapsulated by OpenVPN (in UDP or TCP according to the mode you have picked).

 

Again, please make sure that your system is tunneling properly. If in doubt please feel free to send us your OpenVPN logs, your routing table (printed after a connection to a VPN server has been allegedly established) and also perform the following test:

 

http://checkmytorrentip.com

 

Kind regards

[kadaj 0]

Sending a doc with relevant information, please take a look.

 

Thanks

[JNavas 0]

Also, please make sure ... that you do NOT forward (this is very important) ports on your router ...

 

Why is not forwarding ports in the router "very important"? It would actually seem to be benign.

When a VPN has been established, it will just be an open port in the router that won't get traffic

because the IP address is not visible to a swarm. So please explain. Thank you.

[Staff 9764]

 

Also, please make sure ... that you do NOT forward (this is very important) ports on your router ...

 

Why is not forwarding ports in the router "very important"? It would actually seem to be benign.

When a VPN has been established, it will just be an open port in the router that won't get traffic

because the IP address is not visible to a swarm. So please explain. Thank you.

 

Hello!

 

If the torrent client has no bind to the tun interface and you forward on the router the very same port that the torrent client listens to (and therefore the same remotely forwarded port as well), an adversary can get a reply (from the torrent client) to packets sent to your real IP AND to the VPN public IP on that port. For an adversary with the ability to monitor/wiretap your Internet line, it becomes therefore trivial to time-correlate your p2p activity (or any service running behind a VPN server) and discover your activities on the p2p swarm (or anyway discover that the service running behind the VPN is YOUR service).

 

Kind regards

[JNavas 0]

 

 

Also, please make sure ... that you do NOT forward (this is very important) ports on your router ...

 

Why is not forwarding ports in the router "very important"? It would actually seem to be benign.

When a VPN has been established, it will just be an open port in the router that won't get traffic

because the IP address is not visible to a swarm. So please explain. Thank you.

 

If the torrent client has no bind to the tun interface and you forward on the router the very same port that the torrent client listens to (and therefore the same remotely forwarded port as well), an adversary can get a reply (from the torrent client) to packets sent to your real IP AND to the VPN public IP on that port. For an adversary with the ability to monitor/wiretap your Internet line, it becomes therefore trivial to time-correlate your p2p activity (or any service running behind a VPN server) and discover your activities on the p2p swarm (or anyway discover that the service running behind the VPN is YOUR service).

 

In other words, the only risk comes from VPN failing/not working.

If VPN is properly established, then there is no risk. [WARNING BY STAFF: THIS IS DANGEROUS AND FALSE INFORMATION]

[Staff 9764]

 

 

In other words, the only risk comes from VPN failing/not working.

If VPN is properly established, then there is no risk.

 

 

Hello,

 

no, totally false.

 

The real risk is much higher. As it has been already explained, the exploit can be performed when the system is properly connected to a VPN server and properly tunneling. The consequences of the attack are that your real IP address is discovered and all the p2p activities or the activities of the service behind the VPN server are related to your REAL IP address. In order to avoid that, do NOT forward ports on your router, or at least close those ports on your physical network interface with a properly configured firewall, or bind the service to the tun/tap interface (but not all services can be bound to a specific interface). Be careful, this is NOT a fault or a problem of OpenVPN, this is a deliberate vulnerability that you voluntarily insert into your system: your system just complies to your orders and OpenVPN can't protect you against your own behavior.

 

Kind regards

[JNavas 0]

 

In other words, the only risk comes from VPN failing/not working.

If VPN is properly established, then there is no risk.

no, totally false.

The real risk is much higher. As it has been already explained, the exploit can be performed when the system is properly connected to a VPN server and properly tunneling. The consequences of the attack are that your real IP address is discovered and all the p2p activities or the activities of the service behind the VPN server are related to your REAL IP address. In order to avoid that, do NOT forward ports on your router, or at least close those ports on your physical network interface with a properly configured firewall, or bind the service to the tun/tap interface (but not all services can be bound to a specific interface). Be careful, this is NOT a fault or a problem of OpenVPN, this is a deliberate vulnerability that you voluntarily insert into your system: your system just complies to your orders and OpenVPN can't protect you against your own behavior.

 

With respect, you are still failing to address how a real IP address could be discovered when a VPN has been properly established and not compromised, and exactly how traffic sent to two differnet addresses could be more easily "time correlated". If an adversary can monitor your IP traffic, that risk exists regardless (even when traffic is encrypted).

[Staff 9764]

 

With respect, you are still failing to address how a real IP address could be discovered when a VPN has been properly established and not compromised, and exactly how traffic sent to two differnet addresses could be more easily "time correlated".

 

Hello,

 

it's extremely trivial for a web server or a p2p client. The attacker just sends packets to the same port both to your ISP assigned IP address and to the VPN server exit-IP address and compares the result. If the victim service replies to packets on both the IP addresses (because the same inbound router port is open) and those replies are consistent (as they are, obviously) both in timing and content, then the attacker have a proof (usable in courts but also useful to criminal organizations etc.) that that service is run by you.

 

 

If an adversary can monitor your IP traffic, that risk exists regardless (even when traffic is encrypted).

 

No: the first attack condition is already that the attacker is wiretapping your line. If the service does not reply to packets to your real IP addres, no correlation proof is possible and the attack fails: it is not possible to prove that a certain service is run by you. The primary point is exactly to defeat those who are wiretapping your line. However, as a secondary but not less important point, there are more subtle attacks which allow an attacker to establish correlations  even if that attacker is unable to monitor your ISP line. All of these attacks are possible only with the misconfiguration of your system, as already said over and over.

 

Kind regards