Help with portmapping Vuze

[Skyline2458 0]

I've read the FAQs and can only roughly gather what it is I need to do but it doesn't specifically say so I'm just not sure. There's #A[remote port as seen outside VPN], #B[local port that remote port maps to], #C[port in routers port forward rule going to local IP], #D[Vuze port].

I know #A and #B but am not sure on #C and #D.

I need Vuze to broadcast the right port since I do direct IP trackers.

[FPyro 2]

Not sure what you mean exactly.

You just want to open the port, right? So connections are incoming?

Then just open vuze, set the port to anything big, like 45678.

Then go to your member Area --> forwarded ports, set the same port ... done!

Now vuze will show port 45678 as open!

[GoXRUTD7k8FfZp5jmvNK4uE6 7]

Yes, it's as simple as FPyro said

Though, make sure to get rid of your router's port forwarding rules for Vuze, having the same ports forwarded there and by AirVPN is a security risk so it's highly recommended to remove the Vuze rules from your router.

Just go to https://airvpn.org/ports/ and input the port you're using in Vuze into the top field, skip the local port and hit Add.

Now, once you've got Vuze open and running, you can hit Check to find the status of the port forwarding. It should be green. It will fail (gray, not reachable / connection timed out) if you're not running your bittorrent client whilst checking.

If you've got two bittorrent clients that you want to use simultaneously you'll have to use a different port number in each, having them both forwarded by AirVPN.

[Skyline2458 0]

Thanks for the answer but that's not quite specific enough.

I want security and anonymity but I want my tracker to properly get the correct port for statistical scrapes. In reference to the below quote from the port forwarding page:

"If you forward a port for a p2p torrent client, do NOT remap it to a different local port and make sure that the torrent client port matches the remotely forwarded port number, otherwise your client will communicate to trackers (if you use them) the wrong port: torrent clients will communicate to trackers the port number you have configured in them. As a result, you will get no incoming packets from the swarm and the torrent client network status token will remain yellow."

"If you forward a port for a p2p torrent client, do NOT remap it to a different local port" - where is this referring to (router or airpvn)?

"make sure that the torrent client port matches the remotely forwarded port number" - specifically which port number in reference to the original post (#A?)

Given this formula: [remote port (AVPN)] -> [local port (AVPN)] -> [incoming router port forward rule] -> [mapped local router port to my pc's IP] -> [Vuze port]

What dummy ports would I fill in where?

[Staff 9785]

Thanks for the answer but that's not quite specific enough.

Hello!

For your purposes, do NOT remap on our system a remotely forwarded port to a different local port and make sure that the torrent client listening port matches the port number you have remotely forwarded on our system.

If you use a DD-WRT / Tomato / OpenWRT router which runs an OpenVPN client which connects to an Air VPN server, then enable DNAT on the router to forward the same port to the machine where the p2p client is running.

If you don't use a DD-WRT / Tomato / OpenWRT router, or anyway if you don't establish a connection from an OpenVPN client running in the router but you establish it from the same machine where the p2p client runs, do NOT open the remotely forwarded port(s) on the router (doing so exposes you to some correlation attacks).

Kind regards

[FPyro 2]

Well now, why make it so complex...

And what exactly is the problem here?

You need to open a port for Vuze, right? It doesn't matter that you run a tracker or not as far as I know, you just want an open port?

Have you done that? Does the Vuze port check give you green lights?

"If you forward a port for a p2p torrent client, do NOT remap it to a different local port" - where is this referring to (router or airpvn)?

Now what the hell? Obviously its referring to the computer running vuze. Set port X in vuze, and don't mess with the local port bindings.

You don't have to...in fact mustn't mess with the router ports at all...they should all stay closed.

"make sure that the torrent client port matches the remotely forwarded port number" - specifically which port number in reference to the original post (#A?)

OMG?! what is not clear about that? PORT X IN VUZE = PORT X FORWARDED BY AIR! jesus christ

That "formula" of yours is nonsense in my eyes. Remote port (airvpn forwarded = X) = local port = vuze port! DONE! Nothing to do with no stupid router. leave the router in peace for heavens sake.

well, good luck. I'm done with this.

[Skyline2458 0]

So what I gathered from what you are saying is: [remote port (AVPN) = 55555(example)] -> [local port (AVPN) = 22222(example)] -> [incoming router port forward rule = no rule:no port] -> [mapped local router port to my pc's IP = no rule:no port] -> [Vuze port = 55555]

That would mean that the 22222 is just for my PC's communications between AirVPN servers and my OpenVPN interface?

With that set up will I still be "unfindable" (yes I made that up but you get it) while still having Vuze report the right tracker statistics?

[Staff 9785]

So what I gathered from what you are saying is: [remote port (AVPN) = 55555(example)] -> [local port (AVPN) = 22222(example)] -> [incoming router port forward rule = no rule:no port] -> [mapped local router port to my pc's IP = no rule:no port] -> [Vuze port = 55555]

That would mean that the 22222 is just for my PC's communications between AirVPN servers and my OpenVPN interface?

Hello!

Apparently there's some very basic misunderstanding.

When your computer connects to an Air server it is inside a Virtual Private Network. All the communications between your physical network card and the VPN server occur through one single outbound port and one single inbound port.

The real headers and payloads of the incoming packets are still encrypted when they pass through the router and they are still encrypted when they pass through your computer physical network interface. They are decrypted by your computer OpenVPN client only on the tun interface.

The real headers and payloads of the outgoing packets are already encrypted when they pass through your physical network interface and your router. They are decrypted only when sent out by our servers.

Therefore:

- the real headers and payloads are visible only on the tun interface

- your router, as well as your computer physical interface, sees only traffic from/to one single IP, one single outbound port and one single inbound port, regardless of applications, protocols, real origins and real destinations of the packets

- the incoming packets are routed to the real destination port only after they have passed through your computer interface

- the outgoing packets are routed to the real destination IP and port only after they have passed through our servers various interfaces

Our remote port forwarding allows a remote forwarded port to be remapped to a different local port (see previous message and instructions on our web pages). Your p2p client notifies the tracker(s) (if any) with the listening port you have configured in it.

Considering all of the above, it should be now clear to you that in order to achieve what you want:

- you must NOT remap a remotely forwarded port to a different local port

- you must set on your p2p client the same port that you have remotely forwarded

- you must not worry about forwarding ports on the router, just keep them all closed (or at least make sure that the remotely forwarded ports are closed on your router to prevent correlation attacks)

ONLY respecting ALL the above conditions your client will report to the tracker the correct port (so your tracker stats are ok), your client will be able to receive incoming packets and your anonymity layer will not be vulnerable to correlation attacks.

Actually, Vuze provides also a useful bind feature which will prevent any correlation attack even if your router is badly configured and will also prevent leaks of your real IP address in case of unexpected VPN disconnection: just bind Vuze to the tun interface.

Kind regards

[Skyline2458 0]

Thanks, that's all very helpful information.

So that means three things then:

1. AirVPN remote forward entry should be 55555 [remote] & 55555 [local]

2. Vuze port should also be 55555

3. No internal router port forwarding rules involving 55555

Regarding:

"If you forward a port for a p2p torrent client, do NOT remap it to a different local port and make sure that the torrent client port matches the remotely forwarded port number, otherwise your client will communicate to trackers (if you use them) the wrong port: torrent clients will communicate to trackers the port number you have configured in them. As a result, you will get no incoming packets from the swarm and the torrent client network status token will remain yellow."

For clarity I would reword it to something like this:

"If you forward a port for a p2p client, keep the local port # the same as the remote port #, which should also be the same port # used in the p2p client. Failure to set all 3 ports to the same # will result in the p2p client reporting an incorrect port # to the tracker (if you use them); p2p clients will communicate their internally set port # to trackers. As a result, you will get no incoming packets from the swarm and the torrent client network status token will remain yellow."