Staff

Hello! In this case you should use your hosts file, so you bypass DNS directly, no need to expose any detail in AirVPN configuration of course. You would need to disable DHCP to have static addresses for the key devices in your LAN, but we don't know if you may like this limitation. Kind regards

Hello! Thank you first and foremost for this valuable information related to the possibility that a plasmashell crash can cause sending a graceful SIGTERM to children apps etc. This should be confirmed or denied as it is relevant. From the correct and precise info that @Tech Jedi Alex provided, you now know that: Network Lock is a set of firewall rules if Eddie is properly shut down, it restores the previous firewall rules if Eddie is killed ungracefully / crashes the rules remain in place, i.e. Network Lock stays "active" Now, you have an unstable environment which might cause a proper Eddie shut down with a tranquil kill signal, so you need to either revert to a stable environment, or keep even the firewall rules that are restored as blocking rules preventing leaks, so you have a "permanent" lock. Of course, should the environment cause modifications even to the filtering table, then a "permanent" network lock becomes impossible and the only real solution is using a stable environment, which would be the healthiest and safest solution. Seeking these types of protection when the operating environment itself is seriously unstable is not logic unless it's an exercise / proof when the assessed risk in controlled condition is zero (therefore do not use this environment for sensitive activity / sensitive data flow). Kind regards

Hello! Please note that guaranteed bandwidth does not mean guaranteed speed. The weakest hop in the routing between your node and the VPN server determines the maximum performance. Nobody can guarantee anything on the Internet as soon as any interconnection with a not owned network takes place, obviously. In your case of course the poor throughput comes from a cap / bottleneck somewhere else, not in the VPN server itself, according to your description. Kind regards

Hello! You should "re-map" the VPN server remote port 33585 to your local VPN interface port 32400 by filling the "Local" field on your AirVPN account port panel. Kind regards

Hello! It's by Telecomix, a group an AirVPN founder co-operated with! https://en.wikipedia.org/wiki/Telecomix Kind regards

Hello! Yes, keep in mind that Plex always listens to port 32400 of the VPN interface, no matter what. Therefore you should "re-map" the server port 33585 to your local VPN interface port 32400 (directly on your AirVPN account port panel). Note: hot change is supported for remote port only, so when you change local port on your AirVPN account port panel, if you are already connected to the VPN please disconnect and re-connect to apply the change. Kind regards

It's so much easier on our state of the art VT100, but the bosses promised that we could have the brand new VT220 for Christmas if we behave, ROFL.

Hello! It sounds like some Mono related problem, can you check your Mono version in your system (and update it if newer version is available)? Kind regards

Hello! There is no Web UI implementation in Eddie, currently. Eddie CLI available options are here: https://eddie.website/support/cli/ Kind regards

Because we can do this only once per year: 😋

Hello! This sounds impossible indeed. There's no way that our servers can guess your public key from a random address. Kind regards

Hello! The WIREGUARD_ADDRESSES environment variable in Gluetun specifies the WireGuard IP network interface address in CIDR format; in AirVPN it is inside the big subnet 10.128.0.0/10. Kind regards

@willowvpn Hello! Please try: pull-filter ignore "ifconfig-ipv6" pull-filter ignore "route-ipv6" pull-filter ignore "redirect-gateway ipv6" pull-filter ignore "dhcp-option DNS6" pull-filter ignore "tun-ipv6" Fixed the linked message as well (it was incomplete). If the problem persists send the whole log, do not cut it. Kind regards

Merry Thrilling Christmas hohohoho heheheheh <evil grin>

Hello and welcome! Another interesting use case is when you live in a country where trying to access the Tor network raises a red flag on you but the HTTP/3 (QUIC) traffic does not. So you first circumvent the blocks via some adequate VPN related protocol that looks like QUIC and only then you fire up Tor, so the regime can't trivially infer that you're trying to use Tor. Sometimes it is more practical and safer than struggling to find Tor bridges: a risk assessment is due, on a case by case basis. Kind regards