Staff

@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

Hello! Actually it should not be necessary. Forwarding unsolicited packets from the router to the final destination is necessary if the listening service is running on a device connected to the router, and the router is the one device which connects to the VPN. What is this listening service running on the router you write about? Maybe packets to it are blocked by firewall rules, have you checked them? Kind regards

Hello! Remote inbound port forwarding is a server side feature that can be comfortably managed from your AirVPN account port panel. Please see here: https://airvpn.org/faq/port_forwarding/ Kind regards

Hello! Please see (and if necessary continue the thread) here: Kind regards

@Fyaskass Hello! We asked for a system report, which provides relevant information in addition to the log. From the log, anyway, we can see that you picked a connection on the IPv4 layer; however, you should try one on IPv6 since you don't have IPv4 connectivity from your ISP. from Eddie's main window select Preferences > Networking set the Protocol used for connection combo box to IPv6 only click Save Test again connections and send us a system report generated by Eddie if the problem persists. Kind regards

Hello! Can you please post a system report generated by Eddie after the problem has occurred? Please see here: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

Hello! OK. What is the OpenVPN version you have no problems with? OpenVPN 2 branch runs external system tools to configure interfaces and routing table, while OpenVPN3-AirVPN and Bluetit try to minimize the external tools to launch. In particular the tun interface configuration is accomplished quite differently by OpenVPN 2 and 3. If you run Bluetit in "WireGuard mode", do you experience the very same issue? Also, do you experience the same issue if you run native wg tools? Kind regards

Hi! Historically, that's for the Black Friday only. 😉 Kind regards

Hello! We reluctantly have to announce gloomy news to you all: Spooky Halloween Deals are now available in AirVPN... Save up to 74% on AirVPN longer plans (*) (*) When compared to 1 month plan price Deal will expire on 2024-11-04 UTC Check all plans and discounts here: https://airvpn.org/plans If you're already our customer and you wish to jump aboard for a longer period any additional plan will be added on top of already existing subscriptions and you will not lose any day. Every plan gives you all the features that made AirVPN a nightmare for snoopers and a scary service for competitors. Just check this frighteningly long list of terrific features if you dare: a clear mission without compromises https://airvpn.org/mission exclusive and comfortable remote inbound port forwarding system flexible, opt-in block lists against malware and other hostile entities. Pick predefined lists, add exceptions or additional blocks, define your own lists, or just use our totally neutral DNS by default improved API functions to let you control and configure VPN features and account settings active OpenVPN 3 AirVPN library open source development WireGuard integration IPv6 support, including IPv6 over IPv4 refined load balancing to squeeze every last bit per second from VPN servers free and open source software for Android, Linux, Mac and Windows easy "Configuration Generator" web interface for access through third party software guaranteed minimum bandwidth allocation GDPR compliance and very high privacy protection standards no log and/or inspection of clients' traffic effective traffic leaks prevention by AirVPN software Tor support via AirVPN software on Linux, Mac and Windows various cryptocurrencies accepted without any intermediary no obligation to use our free and open source software to enter AirVPN infrastructure. Interoperability is an AirVPN priority. perfectly clear and easy to read Privacy Notice and Terms https://airvpn.org/privacy No tricks, only treats! We witch you a spooktacular Halloween! AirVPN Staff

@jssi Hello! UDP seems blocked. Also, the Mullvad tunnel we see in the report is up, therefore conflicts will arise on the main routing table and also for the overlapping of Mullvad/AirVPN VPN range (subnet). Please check any packet filtering tool both on your Fritz!Box and your system and make sure that they do not block UDP. Moreover, please do not keep the Mullvad tunnel up while you run Eddie (and vice-versa). You may also test a connection with WireGuard. You can switch to WireGuard on Eddie's "Preferences" > "Protocols" window. Kind regards

Hello! Thank you very much for your tests. Can you please post the whole Bluetit log and also tell us your exact distribution/OS name and version? Also, if some specific action is needed to cause the crash, can you describe it step by step to help us reproduce the failure? Kind regards