Staff

Hello! That's not true in general. It's true only if Plex listens to the "public" (as it is called in Plex settings) port 32400 too. With the previous configuration the VPN client received packets on tun interface (the VPN virtual network adapter) port 32400, while Plex listened to port 39196. Now the user has resolved the problem through the provided suggestion, i.e. the remote port is forwarded to the tun interface port which is the public listening port on Plex, NOT 32400. To be clear: now the Plex server listens to public port 2***7. The port panel of the user is configured to forward remote port 2***7 to client port 2***7 (same port number). Everything works as expected. If the VPN server remote port were forwarded to VPN client port 32400, the same problem would occur, as the packets would arrive on tun interface port 32400. Plex would not listen to tun interface port 32400. It would therefore see nothing on VPN interface port 2***7, the port it listens to ("public port"). Please make sure you understand that physical interface port 32400 is not VPN interface port 32400 and that Plex listens always to port 32400 of the physical interface while you are free to configure any public port you wish. It's important to understand all of this. We have reviewed some old tickets related to Plex problems caused by exactly this misunderstanding. As an additional didactic aid, please visualise the flow of incoming packets when the listening programs are running on the same system that's connected to the VPN: when such packets pass through the system's physical interface, the underlying header and payload are still encrypted, so the port set of the physical interface never plays a role in the incoming virtual private network packets. Here above you find the explanation, it might come handy to you and any other Plex user. Kind regards

Hello! You may tell Eddie to activate Network Lock at startup in the "Preferences" > "General" window to have your rules overwritten. The total block you enforced will prevent Eddie (and any other program) to communicate to and from localhost. This may break several programs, you should add allow rules to and from 127.0.0.1 at least. Eddie frontend and backend talks to each other via TCP on 127.0.0.1. Please note that the activation of Network Lock requires that Eddie can talk to the backend process (the only one running with root privileges) so the total block you enforced can not be circumvented by Eddie, not even if Network Lock must be enforced as soon as the program is launched. Kind regards

Hello! Yes, as we wrote (and you couldn't know, but now you know) @robzeta had forwarded, on the AirVPN port panel, remote port 39196 to local port 32400. Therefore Plex, which was configured to listen to public port 39196, could never receive packets. Also (and you couldn't know it as well) the forwarding was active only for UDP (note that the port tester performs a test only in TCP and correctly returned error 111 as expected). Now, @robzeta has deleted port 39196 altogether, so let's wait for the new tests. Another clarification, this time for us: in the Plex documentation here https://support.plex.tv/articles/200289506-remote-access/ we read: Therefore we guess that the Media Server refuses to listen if you don't have an account or you did not sign this account in to some other service managed by Plex Inc.? Can you confirm? Kind regards

@DrunkenDesperado Hello! Please test WireGuard and verify whether you have any improvement or not. In order to switch to WireGuard: from Eddie's main window please select Preferences > Protocols uncheck Automatic select a line with WireGuard (example WireGuard, port 58120...). The line will be highlighted click Save and test connections to various servers in various locations Kind regards

Hello! Nearly impossible to say without more information. To begin with, please mention your Operating System(s) name and version, the program you run to connect to the VPN servers, the settings of this program and the traffic management rules of your ISP (if any and if you know them; they should be mentioned in the contract or in the public information under "Quality of service" or "bandwidth fair use" or "traffic management" sections). Kind regards

Hello! Here a serious complication might have entered into play. UFW does not support nftables, while all modern distributions are based on nftables for the packet filtering system. Eddie does support nftables and correctly uses it. UFW must rely on translations back and forth performed, for example, by iptables-nft. However the translation tools do what they can, but if you start mixing iptables with nftables syntax rules, by experience we know that "bad things will happen". If you have an nftables based distribution and you want to use Eddie's Network Lock (or the AirVPN Suite) you have two options: 1. avoid UFW, which after all is a frontend of a frontend of a frontend, by disabling it, and operate on the firewall rules directly with nft. To disable UFW the following command should be sufficient and permanent: sudo ufw disable 2. Alternatively, force Eddie to use the iptables-legacy system. Open the "Preferences" > "Network Lock" window and select "iptables-legacy" on the "Mode" combo box. By forcing consistency of rules' syntax by all the programs operating on firewall rules the translator tools should work properly. However, if your system is still entirely based on iptables (no nftables at all) then the above can not be the cause of the problem and it's necessary to look elsewhere to find the problem roots. Kind regards

@robzeta Hello! Port 39196 reserved to your account is UDP only, so failure on TCP is expected. If Plex needs TCP as well please act accordingly on your account port panel. Furthermore, port 39196 is forwarded to your VPN IP address port 32400, so Plex will never receive any packet on port 39196. This explains also the connection refused error on port 39196 (a test which our port tester runs anyway): your system receives packets on port 32400 and correctly resets the connection. Adjust this setting too. Kind regards

Hello! The cracker wouldn't be able to decrypt it (interception can be performed with or without your configuration file), but he/she would be able to connect to VPN servers with your account key. You may delete or renew keys anytime: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s (full duplex) server located in Kyiv, Ukraine, is available: Altais. Altais supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Altais will replace Alcor in the same location. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses and 4096 bit DH key not shared with any other VPN server. You can check the status as usual in our real time servers monitor: https://airvpn.org/servers/Altais Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Staff

Hello! You need traffic splitting on an application basis or virtualization. Plenty of solutions are available and covered in these community forums. Implementations may vary according to your Operating System. Kind regards

Hello! As you might have read it's not the only one. In addition, other safeguards may be in place, but we do not believe it is appropriate to disclose now the details of each and every technical measure that we will implement on top of those mentioned. Kind regards

Hello! We're terribly sorry, it will not be possible. Kind regards

Hello! Of course you can ask for (and obtain) a refund, as you may have read in the original message. In order to ask for a refund you may either drop a ticket (click "Contact us" from the web site upper menu while you are logged in) or write an e-mail to support@airvpn.org, as you prefer. Kind regards

Hello! That's a pity, and apparently an unnecessary limitation. In our infrastructure WireGuard lives in one 10.128.0.0/16 subnet to make the key <> IP address static correspondence more manageable (WireGuard can't assign addresses dynamically), no need to change subnets and public key on each server. Kind regards

Hello! Well, of course... that's the servers' public key, you can't change it! Kind regards

Hello! With AirVPN you may have multiple keys per account and you may use unique keys per profile, please see here: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Kind regards

Hello! We will act with due diligence to prevent access to residents of Italy on the purchase page. Blocking Tor on the purchase page may be unnecessary as the payment processors themselves block payments from Tor and they are certainly quite effective (probably more effective than we could ever be), but yes, if the action were within due diligence we might seriously consider it. It shouldn't be strictly necessary, both for the binding declaration where a user states he/she is not a resident of Italy, and for the identical blocking on the purchase page. It might add useless redundancy and incorrectly block non-residents of Italy, but again, see above. We can't see why not. Tor remains a viable, perfectly legal tool in most countries, Italy included, aimed at facilitating the exercise of some fundamental rights, and it is very good especially when high speeds and UDP are not required. Kind regards

Hello! The following errors: hint to an UDP block. Please check any packet filtering tool both on your router and system and make sure that no UDP block is enforced. If you find nothing blocking, it is possible that your ISP is the culprit. Maybe the block is against OpenVPN and not against UDP. To discern, please try a different connection mode: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard. The line will be highlighted. click "Save" and re-start a connection to apply the change please make sure to test a few servers in different locations around your node If the above connection mode fails too, please try the following, different connection mode: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select the line with OpenVPN, port 443, protocol TCP, entry-IP address 3 (three) click "Save" and re-start a connection to apply the change please make sure to test a few servers in different locations around your node Kind regards

@qwertyuiopas Hello, we think the moderator locked the thread correctly because you yourself wrote that the problem was resolved: Since you just wrote the opposite we have re-opened the thread and merged it with your new message, no problems. Kind regards

Hello! Customers who are not residents of Italy and purchased the service from outside Italy should not suffer any unintended suspension, even if they are transiting through Italy (for example for tourism). Should any problem arise please contact the support team. We will carefully explore different, feasible options when necessary, and this is one of them. This is because the authority will seek to enforce blocks on any company offering services to residents of Italy, regardless of whether the service is offered from another country and jurisdiction. See, for example, the request for DNS poisoning filed to Quad9, a non-Italian company that operates DNS servers outside Italy but accessible to residents of Italy. It is remarkable to note that Quad9 challenged a similar request from Sony in court, and won. Kind regards

@trekkie.forever Hello! In general OpenVPN doesn't manage this situation properly. To automate the procedure you are forced to perform, you may consider to run a script (with root privileges) on wake up. This script might send a SIGTERM to OpenVPN and re-start it, or perhaps just sending a SIGHUP to OpenVPN might suffice (to be tested though). Some ideas for systemd based Linux systems: https://unix.stackexchange.com/questions/152039/how-to-run-a-user-script-after-systemd-wakeup Kind regards

Hello! Please generate and send a system report in the following way: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Avoid screenshots whenever possible. From what we can see from the screenshot, anyway, the problem is caused by a potentially alien "VPN Client Adapter - VPN" which might have been installed by some other application. If we're correct then the solution is immediate, see here: https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?do=findComment&comment=225323 However, if the problem persists, please send us the mentioned system report. Kind regards

Hello! We regret to inform you that we will be discontinuing the service to residents of Italy as of February the 19th, 2024. From the above date, any user registering on the platform must declare that he/she is not a resident of Italy. The purchase page will have IP address-based geolocation and will not be served to IP addresses located in Italy. We will not interrupt the service to current subscribers until the natural expiry date and the refund policy will be granted as usual. REASONS FOR DISCONTINUATION The so-called "Italian Piracy Shield" is a legal framework with implementing regulation by AGCOM (Italian Telecommunications Authority) that forces operators offering services in Italy to block access to end services through IP blocking and/or DNS poisoning. The list of IP addresses and domain names to be blocked is drawn up by private bodies authorised by AGCOM (currently, for example, Sky and DAZN). These private bodies enter the blocking lists in a specific platform. The blocks must be enforced within 30 minutes of their first appearance by operators offering any service to residents of Italy. There is no judicial review and no review by AGCOM. The block must be enforced inaudita altera parte and without the possibility of real time refusal, even in the case of manifest error. Any objection by the aggrieved party can only be made at a later stage, after the block has been imposed. For further details: https://www-wired-it.translate.goog/article/piracy-shield-agcom-piattaforma-streaming-pirata-calcio-segnalazioni/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp The above requirements are too burdensome for AirVPN, both economically and technically. They are also incompatible with AirVPN's mission and would negatively impact service performance. They pave the way for widespread blockages in all areas of human activity and possible interference with fundamental rights (whether accidental or deliberate). Whereas in the past each individual blockade was carefully evaluated either by the judiciary or by the authorities, now any review is completely lost. The power of those private entities authorized to compile the block lists becomes enormous as the blocks are not verified by any third party and the authorized entities are not subject to any specific fine or statutory damage for errors or over-blocking. By withdrawing service availability from Italy, AirVPN will be able to stay outside the scope of the framework and maintain integrity and efficient operations. We certainly sympathise with our fellow Italian citizens, and we will be happy to offer advice and alternatives. We would also like to remind them of our more than ten years of support for the Tor network, which is freely accessible even from Italy, and which is becoming increasingly reliable and fast thanks to a myriad of small contributions like ours. Kind regards and datalove AirVPN Staff

Hello! Unfortunately not, you need Eddie 2.23.2 or higher version. Kind regards

@kbps Thank you. Very puzzling, we can just confirm that from our testing lines in Holland and Italy the performance we get while connected to UK M247 servers is very similar to the best performance you got on the screenshot you sent us. We use WIreGuard with 1320 bytes MTU. Mullvad software forces 1280 bytes, please try with 1280 bytes MTU when you connect to our servers too. To change MTU in Eddie Desktop edition (2.23.2 or higher version required) open the "Preferences" > "WireGuard" window. If you use WireGuard configuration file, please edit it with any text editor and add in the [Interface] section the following line: MTU = 1280 Test also bigger MTU up to 1400 bytes. Kind regards