Staff

Hello! As you might have noticed by now your domain name resolves into the wrong IP address (128.127.104.80 in place of 128.127.104.86). Be aware of different AirVPN server IP addresses. The matter is explained here and you can also obtain in real time the correct IP address from your AirVPN account port panel (click "Test port" and note down the IP address). Last but not least, you may also consider AirVPN DDNS (service included by default in every AirVPN plan) which is designed also for comfort in similar situations. Kind regards

Hello! Developer's options in Android system. This article explains everything step by step for any Samsung Galaxy: https://www.samsung.com/uk/support/mobile-devices/how-do-i-turn-on-the-developer-options-menu-on-my-samsung-galaxy-device/ Kind regards

Hello! We're sorry we do not implement the specific obfuscation mentioned which requires pre-shared keys, a specific server side configuration and various over-complications to maintain compatibility with current profiles. The solution adopted by @tanaka is much better, as it is a drop in replacement and does not require any modification on the server side, so you can use it anytime with AirVPN. Kind regards

Hello! We're very glad to inform you that in the coming days, according to our infrastructure expansion and improvement plan, all the servers in Los Angeles, New York City and Phoenix will be replaced. The new servers will have much more powerful hardware and all of them will be connected to a 10 Gbit/s (full duplex) port with guaranteed bandwidth. Therefore, the infrastructure in the mentioned locations will be entirely upgraded to new 10 Gbit/s servers, with 3 servers in LA, 3 servers in Phoenix and 4 servers in New York City. The current servers will be decommissioned on November the 1st. Please note that all the new servers will have new IP addresses. Connectivity will be very similar, with the notable addition of GTT and Zayo as fiber and tier1 transit providers. Kind regards and datalove AirVPN Staff

@Maggie144 Hello! The bug has been fixed and you will see soon an Eddie 3.2.1 Release Candidate. Thank you again! Kind regards

Thank you again! The issue has been addressed, as VPN apps must not offer anymore the option to disable persistent notification. You will see very soon an Eddie 3.2.1 Release Candidate. Kind regards

Hello! The key icon is a persistent notification by Android (and not by Eddie) showing a locked to a specific network traffic status. For example you may have the key icon even when a VPN tunnel is inactive but "Always on VPN" and "Block traffic if VPN is inactive" are enabled for Eddie, due to the integration of Eddie with Android's notification system. The Eddie app's persistent notification icon (a cloud in a circle) appears when the VPN tunnel is up and offers the additional comfort to stabilize the VPN, see at a glance stats, disconnect, and (for OpenVPN) pause and resume the tunnel. Note that Android 7 and older versions don't have the quick tile buttons. An additional clarification about "OpenVPN for Android" app you mention and Eddie. Android enables OpenVPN for Android notifications automatically according to a legacy behavior for all apps built with SDK < Android 13. The behavior on apps built with SDK >= Android 13 (like Eddie 3.2.0) is different, notification authorization must be explicitly enabled by the user. Since August the 31st, it is mandatory to build an application with Android 14 SDK to have it accepted (even as an update) on the Google Play Store. Thank you! Kind regards

Hello! We're glad to know that the problem is resolved! Yes, the idea of Google Android designers was to bring you to the proper setting option(s) directly without forcing you to search for it on the whole sea of settings. Frankly we think this is a good idea. It's not an Eddie screen, you only see Android settings. If you see discrepancies in the settings, they are not due to Eddie. You could have a different setting manager or who knows, but Eddie simply doesn't have Android setting screens. This is a grave danger and a mistake because without a persistent notification the VPN connection established by any app through the VPN API can be interrupted under many circumstances, so you will have traffic leaks, potentially (for sure, sooner or later). Note how "Always on VPN" and "Block traffic if VPN is inactive", two Android settings, are in synergy with the notification and leaks prevention. You don't have two different icons with the same meaning, each icon has its different and unique role. Without persistent notification you shouldn't use a VPN app at all because you may lose the connection anytime. However, and of course, Eddie should not crash, and this matter will be investigated as soon as we can see your logcat. For this purpose please send us a report when the problem occurs. To do so, open the "Log" view, tap the paper plane icon and send us the link that Eddie will give you back. For privacy reasons please send it through a ticket by clicking "Contact us" from our web site or by writing to support@airvpn.org Kind regards

Hello! The Network Lock rules are not the problem as they allow traffic to all local networks. Only a future Network Lock will have the option to stricter rules which can be enforced optionally when necessary. The problem is the other one we mentioned and it will be tackled in a near future Suite version for WireGuard connections. In the meantime you can consider the solution suggested in the previous message. Kind regards

Hello and thank you! Bug confirmed and reproduced. We will fix it expeditiously and make a new 3.2.1 version to be tested in the near future. In the meantime, to avoid the problem, you have two options: if you try a connection from a server list when WiFi is off and LTE is off too, do not kill ungracefully the app. Just wait 60 seconds and the app will tell you that there's no network and will remain operational if you kill without grace the app anyway, you can delete the app's cache from Android app settings (instead of de-installing and re-installing the app) in order to re-enable the app to start properly Kind regards

@rkdover Hello! The feature to make local networks available during WireGuard connections will be available in the Suite 2.0.0 next beta version, similarly to the Android implementation. In the meantime, you can consider to run WireGuard with a configuration file explicitly compiled to have traffic to local network excluded from the VPN routing: https://airvpn.org/forums/topic/55801-wireguard-access-local-network/?do=findComment&comment=217458 Network Lock rules implemented by the Suite already allow traffic to/from all the local subnets. A stricter Network Lock to block traffic even for the local network is under evaluation. Kind regards

@nva Hello! Each VPN server runs its own DNS server. The authoritative server for the mentioned domain names either blocks a lot of DNS IP addresses (not only AirVPN ones, as you noticed) or is malfunctioning. In both cases you would get a SERVFAIL error message. Kind regards

Hello! That's expected due to the quoted configuration. The 30 minutes delay is unexpected. Please take care to re-start your qBittorrent client each time you re-start a VPN connection. If the problem re-appears, please report again and also open a ticket to let the support team verify the correct configuration on the server side. Kind regards

Hello! Thanks for the info and to let us know that an AsusWRT Merlin based router can handle perfectly an OpenVPN server behind an OpenVPN client almost out of the box and without manual configuration required. Kind regards

@Dia Hello! Are you able to turn on the Allow notifications switch in the screenshot you sent us? By turning it on the problem should be resolved. Can you tell us the brand, model and exact system version of your device? Kind regards

Hello! Wait, you must enter the key label. The label is just the name you assigned to the key in your AirVPN account device panel. Kind regards

Hello! For this purpose running an OpenVPN server and client at the same time on the same router is perhaps a useless complication. A simpler solution is just connecting the router to some AirVPN server, forwarding and pre-routing the ports needed for the listening services of the machines behind the router to the proper destination (both on your AirVPN account port panel and from the router's tun interface), configuring the proper DDNS for each port, and reach from the Internet the services running on the devices behind the router. This simple solution, however, is not suitable in case you need more than 5 ports (if you need more, contact the support team). Kind regards

@cccthats3cs Hello! We have removed this limitation. If anybody else experiences this problem please contact us via support@airvpn.org or anyway write to support@airvpn.org to bypass the limitation (the support team will then sort your mail messages in the proper ticket). Kind regards

Hello! Yes, connection's key ("device" in the Client Area) can be selected via Goldcrest's --air-key option: https://airvpn.org/suite/readme/#goldcrest-configuration or via Bluetit's run control file option airkey: https://airvpn.org/suite/readme/#bluetit-configuration Please note that the key string is case sensitive. Kind regards

@cccthats3cs Hello! For the readers too. The problem was most probably caused by a rare conflict caused by a vicious bug which has been resolved. Haedus runs on a kernel based exclusively on nftables, but with iptables-nft userspace utility still available when the system basic files are uploaded in RAM. An old script of ours invoked iptables-nft once during the bootstrap and triggered the feared "translations" back an forth between iptables and nftables, which in turn caused rare troubles in adding and removing rules for remote inbound port forwarding. This series of unfortunate events was resolved by fixing the script (no more iptables-nft, of course). Fix deployment has been ongoing on the infrastructure since a week ago but was not yet rolled out on Haedus. The fix is deployed gradually because in general the bug does not cause these issues and also because a complete clients disconnection is required to bring back the system to a "no nft/iptables hybrid" status. Thank you! Kind regards

Hello! Yes, in this case it's not reachable at all. Not necessarily. You should have forwarded port 8843 on your AirVPN account port panel (you did it by re-mapping port 28443, so make sure to connect to port 28443 of your DDNS, and not 8843) and you must make sure that the GUI web app binds to the OpenVPN client's tun interface and not to OpenVPN server's tun interface or to the physical network interface. A router's GUI web app may also refuse any connection outside the local network for security reasons, please check. Please also consider to stop the OpenVPN server to discern the exact problem with the router web interface. It is the subnet of the OpenVPN server your OpenVPN client connected to. The OpenVPN server assigned to your OpenVPN client tun interface (a virtual network interface) the 10.16.170.244 adress, in the 10.16.170.0/24 subnet. The route added in table ovpnc1 ("OpenVPN client 1") and quoted in your message looks very correct. Kind regards In this context "internal" IP address is very ambiguous. That's probably the IP address of the router's physical network interface for the WAN or LAN, in turn assigned (if you use DHCP) by the ISP router your Asus router is connected to. Kind regards

Hello! Thank you for the clarification, we should have understood this setup since your very first message. This is likely the problem. Running an OpenVPN server and an OpenVPN client on the same host at the same time requires some care. Latest Merlin firmware version might support it out of the box, please verify. If this particular configuration is possible, remember that your OpenVPN server will probably be reachable from the Internet on your real IP address:1194, not on the VPN server exit-IP address, because OpenVPN server and client will necessarily rely on different tun interfaces and routing tables. Is there anyone reading this thread who achieved a proper setup of an OpenVPN server and an OpenVPN client running simultaneously on a Merlin router, with the OpenVPN client network receiving packets for the OpenVPN server subnet? Kind regards

@chbni Hello! The OpenVPN log shows a successful connection, so everything seems fine here. Just for a cross-check, please browse ipleak.net from a browser of a device behind the Asus router and verify that your "real" IP address does not appear anywhere. If it does, this potential issue: could be resolved by upgrading the firmware. By upgrading to AsusWRT Merlin you will also have the option to forward ports to a device behind the router itself, should this need arise in the future. About remote inbound port forwarding, we're back to square 1 so we will be waiting for the answer to our first question in our first message: what is this listening service running on the router you write about? Kind regards

@cccthats3cs Hello! This account can not connect to VPN servers so we can't verify on our side (you probably have another account). Please open a ticket or a thread to let us know your account name in AirVPN if you want to have us verify that the settings for your account on our side are properly implemented in the VPN servers you connect to. Kind regards

Hello! No, it is not possible as the traffic flow is still encrypted on your ISP infrastructure, including your home ISP router. You were correct and this was assumed as already working. You mentioned a problem about remote inbound port forwarding, which is an additional feature. If the problem pertains to the connection by the router to the VPN servers, then it must be re-assessed: in this case remote inbound port forwarding does not even enter into play. Please clarify: can the router connect to AirVPN servers? if not, please send us the OpenVPN log taken after a connection attempt has failed is the problem related to remote inbound port forwarding? if so, please answer to the previous question and clarify: is the listening service really running on the router, or is it running on any device behind the router? Kind regards