-
Content Count
11043 -
Joined
... -
Last visited
... -
Days Won
1866
Everything posted by Staff
-
Hello! Very puzzling, please open a ticket because we want to check directly the server rules inside the server while you are connected to that server to discern whether the problem is on the server side. Kind regards
-
@chimney sweep It's impossible in theory that packet forwarding goes on and off during a session because prerouting rules for a node are changed only at the start and at the end of a session, not during the session itself., there's just no existing code to do that. (*) Some twist comes from WireGuard, due to its inability (by design, intended) to detect the end of a session, but nothing that can't be resolved in a matter of minutes thanks to the enforced pre-assumed timeouts. Do you mean that sometimes you have packet forwarding working, and on another session to the same server you have it not working? If so, you already wrote it in many other messages in this thread. If you run both WireGuard and OpenVPN, do you notice any difference? (*) EDIT: not totally true: if ports are modified by a user from the web site control panel, then the controlling servers send commands to all VPN servers the user has active sessions with in order to alter the rules accordingly. - pj Kind regards
-
@ciudad Hello! It's not planned at the moment because it's more comfortable for us the current single tls-crypt key. tls-crypt 2 doesn't change anything for the client, while on the server side, in our specific case, it would be useless because we maintain tls-auth for backward compatibility,. Any denial attempt would remain potentially possible via tls-auth, hence we would have a complication for nothing. However when we drop tls-auth (we're afraid not in the near future because of the amount of old OpenVPN versions connecting to our service) then tls-crypt-2 will become attractive indeed.. Kind regards
-
Hello! @OpenSourcerer and any other Arch user. Slightly Off Topic: if Eddie fails with Arch with kernel 5.15.x and nft (the userspace utility) is installed, please contact us. Eddie gives priority to nftables if it finds nft, so if Network Lock does not work even when nft is available something else might be going on. Please check if you can and if you find any malfunciton even with nft installed send us (in a ticket if possible) Eddie system report showing the failure. Also specify the nft version. Kind regards
-
Hello! Good solution for Eddie because Eddie doesn't let you pick the firewall framework. With AirVPN Suite, if you prefer the newer kernel, you don' need to downgrade, you can just tell the software to use nftables for Network Lock. And you can do the same with Eddie too. Just install nft and Eddie will prefer nftables, no need to downgrade kernel, and the Network Lock will be fine. Kind regards
-
[COMPLETED] WireGuard beta testing available
Staff replied to Staff's topic in News and Announcement
If you youtube 'Christian Mcdonald', he explains everything in his series of videos. He's also overseeing the wireguard package for netgate, and talks about the whole process and where he wants to take it in the future. Hello! Speaking of netgate.com, we found this article on it which looks good: https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html In order to fit it to AirVPN, please generate a configuration file for WireGuard and the server or country you wish from the Configuration Generator. It's a text file inside which you can find the settings/values you need. Kind regards -
@OpenSourcerer @tudou Hello! We have resolved the problem. Kind regards
-
Thank you for your great feedback and the head up. Lists should have been updated every 24 hours but the procedure started failing recently. We are working on it to detect the problem and restore the normal update every 24 hours. EDIT: problem detected and fixed. Kind regards
-
@cheapsheep @eburom @magnavoid @OpenSourcerer Thank you very much for the bug report, the issue will be investigated very soon. In the meantime please force nftables (if available, and remember that userspace utility nft is currently required) as @cheapsheep suggested to circumvent the problem. EDIT: Eddie, Hummingbird and Bluetit assume that iptable_* modules exist if iptables exists. This is no more true in some distributions, where iptables userland utility exists but iptable modules don't (and it would be false even in customized kernels compiled with embedded iptable). We will be working on a more robust implementation. @eburom Both implementations are logical and probably the "Right and Just" one does not exist. If Bluetit renounced to the connection when Network Lock fails it would leave the machine completely exposed (remember that Bluetit is a daemon) because it has no way to block the traffic when the firewall fails (*). If Bluetit goes on at least it tries to connect the machine and establish a "tunnel". In early Bluetit implementations Bluetit aborted the connection if Network Lock failed, now the other solution has been preferred even after consultation with users. (*) It might sabotage the routing table or the gateway or it might turn off the network interfaces to isolate the machine completely, but this solution is considered too invasive and it is unacceptable for various system administrators, especially those who run remote servers. Kind regards
-
@chimney sweep Hello! Understood, we are investigating, there's no need that you keep posting. Kind regards
-
@chimney sweep Hello! Feel free to specify the server. To forward an inbound port to a specific node, a server applies prerouting rules created (according to customer's settings), transmitted and ordered by our backends to the VPN server. Failure of rules enforcement only on one server hints to a problem of some kind related to that server, and by telling us the specific server you experience the problem on you help us troubleshoot those cases which are not detected by the automatic supervision and warnng system. Kind regards
-
@JamesFrancis Hello! Please try connections to specific Swiss servers and note whether you can connect to some of them. We operate different datacenters in Swiss so it seems impossible that they have the same problem at the same time. However, when you use the FQDN ch3.vpn.airdns.org, you end up to a specific server which the system reputes "the best in Swiss", therefore checking single servers one by one is essential to understand the nature of the problem. Then, please send us the list of servers you can't connect to and a log showing the connection failure. Kind regards
-
Hi, that's true. Perhaps the most practical solution is entering a transitional state by leaving some forum dedicated section still to Invision and rewriting (when the license allows it) some critical parts we don't like of those sections, while other important parts and pages will be completely detached from Invision. Then, in a farther future, eliminate the remaining Invision parts one by one. Kind regards
-
Hello! Of course, absence of evidence is not evidence of absence, but at least you can't find any proof that any identity of our customers has ever been disclosed, while such cases are notorious for various competitors. While science can't prove that there are no pink donkeys, because scientific inquiry can't bring evidence of absence, the scientific method forces you to bring a proof, specifically at least one pink donkey., to show that they exist. Now, either you bring some proof for your insinuations, or you are just another trolltard. Not at all, or at least "not necessarily",. You can still access our onion web site, or even access our regular web site through Tor, which is a much stronger clue against your fears than any audit can provide because an audit which is paid by the audited can not be trusted. Can you tell us what good the excellent audits performed on ExpressVPN (who hired CIA intelligence agent who worked for UAE government to crack activists and journalists devices) or PIA and CyberGhost (which are owned by an adware and malware specialized Israeli company) brought to customers? This shows your ignorance on how Tor works, shame on you. The power of Tor is mainly due to the fact that you don't need an audit of every single Tor relay and that end-to-end encryption has wiped out Tor malicious exit nodes which could intercept your unencrypted communications and take advantage from them even though the exit-node does not know where they come from. Please get informed before you publish such nonsense. Kind regards
-
@regvpn Therefore you are not able to substantiate your imaginary claim We acknowledge it and we assure the community that "regvpn" will not be able to troll here and pollute the community forum anymore.
-
ERROR: RESOLVE_ERROR with bluetit
Staff replied to lex.luthor's topic in Troubleshooting and Problems
@lex.luthor Hello! Please check rules with Bluetit not running as well. Make sure that INPUT and OUTPUT chains policy is, for both chains, set to ACCEPT when Bluetit is not running. If it's not, make sure to flush all rules and set the proper policy before you start Bluetit again. Registering a root process like Hummingbird as a "service" is another Window-ish abomination made easy by systemd which incredibly discourages true daemons even in the documentation! In general it is a bad idea. Use real daemons like Bluetit instead as you are correctly doing now, please do not follow the Windows-ish logic of systemd, at least in this case. Feel free to keep us posted! Kind regards -
Hello! It's an Invision Power Board feature we don't like as well, but it's used only for your comfort. We do not exploit (if it was even possible) such data to profile you. We are anyway dropping IPB (the procedure is not trivial, we started it months ago but some more time is still needed). Also note that our web site and apps do not use tracking cookies, trackers or anything else and we run scripts to wipe out some IPB caching, just in case it was dangerous. If we had known in 2010 that IPB would have evolved in this way, our initial choice for the community and non-community forum would have probably been different ProtonMail had a court order to log and transmit the IP address of a specific account, they actually did not do it before they were served the subpoena. It's anyway a mail related issue, not a VPN one, where a subpoena can't indicate an e-mail address (we do not require an e-mail address in account data). Please note that contrarily to what numerous "competitors" did, in 11 years of activity AirVPN has never disclosed the identity of its customers, not a single one. In any case some skepticism is welcome and we invest very much on Tor (4% of worldwide Tor exit nodes traffic is supported economically by AirVPN), which is free for everyone and offers a very robust layer of anonymity. Use Tor for free in any case and especially if you can't trust us. Last but not least, the problem you have correctly underlined is negligible when compared to other dangers you must take into account. We wrote an article in 2013 to suggest how to defeat powerful adversaries, even when you can't trust one of your providers (including the VPN). It's an 8 years old article but it's still good and valid: https://airvpn.org/forums/topic/54-using-airvpn-over-tor/?tab=comments#comment-1745 Kind regards
-
ERROR: RESOLVE_ERROR with bluetit
Staff replied to lex.luthor's topic in Troubleshooting and Problems
@lex.luthor Hello! Yes, some progress in names resolution which is now successful (even though we still see an initial failure, then the resolution is successful and correct). Unfortunately now a new problem has come out: UDP appears as a blocked protocol. Might it be that you're running some other firewall frontend such as ufw that's creating some interfering rules? We remember (but we could be wrong) that some default ufw configurations create custom chains and that UDP to some ports get blocked. If that's the case can you please try again with ufw (or any other custom fw frontend) completely disabled? The error message: Nov 25 21:39:38 betelgeuse bluetit: UDP send exception: send: Operation not permitted is a typical error hinting to a local, and not external, system UDP block. Kind regards -
@Pwbkkee Hello! The system does exactly what it's instructed to do and you are clearly warned that such a situation may occur if your run systemd-resolved or a network manager. The traffic flows only between your router and your system and any final public destination that's not the VPN server is blocked on the system where the AirVPN Suite runs. It's not blocked on devices where Goldcrest and Bluetit don't even run. This is so obvious that we did not think it's necessary to explicitly explain it. You can't consider Goldcrest/Bluetit responsible for something that your router, and not your system, does: Goldcrest and Bluetit do not even run on the router and they have no control over it. Thank you anyway for your point of view, we will consider to specify that the AirVPN Suite can't magically influence the behavior of devices which it doesn't run on. Kind regards
-
ERROR: RESOLVE_ERROR with bluetit
Staff replied to lex.luthor's topic in Troubleshooting and Problems
Hello! Sure. From your descriptions we assume that it's systemd-resolved the daemon handling DNS setting in your Ubuntu 20 system, so we suggest you check here: https://unix.stackexchange.com/questions/588658/override-ubuntu-20-04-dns-using-systemd-resolved Do not miss this bug, just in case it's relevant in your case: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1774632 The bug is pointed out in the above linked thread but in a minor comment and it could be missed. When you know it, patch is straightforward. If you need a recommendation on DNS servers, we suggest Quad9 (9.9.9.9) and OpenNIC, also see https://www.quad9.net/ and https://www.opennic.org If we're wrong about our first assumption, please tell us how your system handles DNS settings and we will point you in the (hopefully ) right direction. Kind regards -
Hello! Suspension of constitutional rights in a state of emergency is foreseen by the Constitution itself, which explicitly mentions sanitary/public health emergency. A state of emergency, in any case, must be approved by the majority of the Parliament, it can't be declared unilaterally by the Government, and has a clear end time, after which it must be renewed again with Parliament majority approval, otherwise it ends. Human rights suspended in Italy have been suspended even in many other countries belonging to the so called "Western democracies", it's not that Italy is so special here. This has nothing to do with the above. It can be enforced even without the state of sanitary emergency. Such subpoena can't acquire anyway data which does not exist, obviously. We already told you very clearly that such traffic data retention does not exist in our infrastructure, and we mentioned the relevant EUCJ decisions on the matter to explain why some EU countries we operate servers in can't legally oblige blanket data retention in spite they try to do so, so they can be challenged successfully if a casus belli emerges.. The Privacy Notice is very clear about it too and you explicitly accepted it years ago, so you may not claim you don't know it under a legal point of view. The Privacy Notice is linked at the bottom of all of our web pages. Here some excerpt for your comfort: Maybe in your fantasy? Please point us where it is stated, because it's not true. Currently in Italy we operate only a geo-routing server, which is irrelevant for VPN data protection. Kind regards
-
@Pwbkkee Hello! You have various options to resolve this problem. You can have e a longer DHCP lease time (1 year is not atypical), you can disable DHCP for sensitive machines, or you may set in one second the proper firewall rule to block traffic to port 53 of your router IP address (after Network Lock has been enabled). Another solution is setting on the router, as primary DNS server, 10.4.0.1 address (VPN DNS address). Sorry that's false. Network Lock is advertised to prevent any traffic leak outside the tunnel to the Internet IPv6/IPv4 addresses, it is not advertised to lock your computer out from your router (i.e. prevent traffic to your local router) . Moreover you are clearly warned that running systemd-resolved and/or Network Manager is dangerous and may cause DNS leaks. We will think about it for port 53 for sure. It's not a big deal by the way: just see above the proposed solutions, in the meantime. Yes, with the obvious exception to your local upstream (typically your router) otherwise your system would be completely isolated and no communications would be possible, including of course VPN connections. Kind regards
-
ERROR: RESOLVE_ERROR with bluetit
Staff replied to lex.luthor's topic in Troubleshooting and Problems
@lex.luthor Hello! Thanks. As you can see the error is different now, AAAA is no more into the game. The problem now is that your DNS doesn't work, not even in IPv4. Fix it or, as a workaround, have Bluetit connect to specific servers, so that it will not rely on names resolutions. Kind regards -
Hello! Italy is in breach of THREE legally binding CJEU decisions on Data Retention from 2014, 2016 and 2020 (*) and we have therefore no servers in Italy (other EU countries are in breach too, and we are already fighting in Spain, so we don't want more "battle/legal" fronts). Apart from that serious and unacceptable breach of human rights in disdain of multiple decisions of the highest court of the European Union (which hopefully will soon cause the opening of an infraction procedure by the Commission against Italy), can you be more specific about how Italy would be cracking down on human rights? About "seizing all the data", nobody can seize data which does not exist. Make sure you do not enter (but who would?) personal data in your account details, we don't even require an e-mail address (but if you use it for your comfort, make sure you use one which can not be exploited to disclose your identity or other personal information). (*) The Court of Justice declares the Data Retention Directive to be invalid https://curia.europa.eu/jcms/upload/docs/application/pdf/2014-04/cp140054en.pdf The Members States may not impose a general obligation to retain data on providers of electronic communications services https://curia.europa.eu/jcms/upload/docs/application/pdf/2016-12/cp160145en.pdf The Court of Justice confirms that EU law precludes national legislation requiring a provider of electronic communications services to carry out the general and indiscriminate transmission or retention of traffic data and location data for the purpose of combating crime in general or of safeguarding national security https://curia.europa.eu/jcms/upload/docs/application/pdf/2020-10/cp200123en.pdf Kind regards