Bellatrix server problem or DPI causing

[bnrrteterstnjrsj45 0]

Hello, can I ask please is that Bellatrix/AirVPN problem at start seeing very few peers in Vuze or if not then it's a DPI using by kazakh governements/Almaline ISP that able inspect-compromizing VPN, OpenVPN technologies is?

 

 

 

It is Blockcheck tool by ValdikSS (https://github.com/ValdikSS/blockcheck/releases) informing in russian about Full DPI on Almaline ISP side. By the way I didn't tried SSH/SSl connection offering by AirVPN, because it's bad idea for me as I active bittorrenter, so, I need best performance for bittorrenting.

 

Almaline ISP in addition stop giving free white IP, instead start giving NAT, is there a way forward ports on OpenWRT's (GoldenOrb by http://ofmodemsandmen.com/downloads.html) router even if behind that NAT by the way? Strange, they start that after start offering 100 Mbit/s, so, that was mostly against bittorrenters between almaliners likely in order to safe "cost-expensive traffic", and now they malefactoring against VPNs too.

 

If needed I can give screenshots about few peers in Vuze after hours staying on Bellatrix server. And kind of I've tried others servers, no sense. It's starts apparently literally in days, yesterday, day before yesterday.

[zhang888 1066]

The ports issue in your torrent client cannot be caused by your ISP DPI when you are connected to Air.

OpenVPN tunnels are encrypted and there is no way for your ISP to restrict any traffic inside them.

 

One of the reasons to use Air when you are behind NAT is the ability to forward up to 20 ports.

You should try forwarding them and/or try another torrent client.

 

The only thing your ISP can do is shape OpenVPN traffic as a whole, in which case you won't

have choice but to use SSL/SSH tunnels - which will cause a little overhead by increase performance.

[bnrrteterstnjrsj45 0]

zhang888, thanks, but as I said there are abnormal very few peers which probably means DPI or any other their special equipments at least dropping connections to forwarded for Vuze incoming ports? Ok, I'll try SSH/SSL connecting, will see, hope it able helps.

[zhang888 1066]

There is no "special equipment" that can read AES-256 encrypted traffic on the fly.

You have to make sure that your tunnel is working correctly and without leaks, and run your tests again.

Preferably with an open standard client like qBittorrent which will also allow you to bind to your local TAP

adapter and not listen on all interfaces, like some torrent clients do.

[bnrrteterstnjrsj45 0]

It's working without binding in Vuze, that's my verified practice, and Vuze is supporting binding.

 

Just after connecting to server running tracerouting and checking packets going through tunnel.

 

 

Looking in Vuze while connected, there are only eth2 (tunnel) and (UDP) (which is uTP which designed work/tide over NAT) interfaces.

 

[zhang888 1066]

There is a strange "Download limit" setting in one of the screenshots.

In any case, I still suggest another client in order to rule out potential software related issues.

Download an Ubuntu torrent and check the peers and speeds.

[bnrrteterstnjrsj45 0]

This is one of the first thing I was made, downloading and incoming peers-connections in it working, but small number of peers in regular seeding. I think I can create ticket and, say, ask for remote helping by Support Desk.

[bnrrteterstnjrsj45 0]

Sorry, it can be code changes about queue system in Vuze, because tons of torrents actually start being in queue especially actively downloading (and seeded by me). I was updated Vuze to last beta yesterday-today, that's can be the cause.

 

Also checked some of servers and speeds are good on most of it, in download even <40 Mbit/s on certain servers and in upload <54 Mbit/s. But on past days it was much worse, so, it can be unstable network itself, AirVPN's or ISP's.

 

And DPI by globalistic inter-governmenting/authorities don't stopping be a huge and bad problem though.