Jump to content
Not connected, Your IP: 216.73.216.51

All Activity

This stream auto-updates     

  1. Past hour
  2. Today
  3. Yesterday
  4. Note I also try to define a file: /etc/systemd/resolved.conf.d/dns_servers.conf [Resolve] DNS=9.9.9.9 Although this works without VPN, then when I try to connect to a server with Eddie, then it fails at "Checking DNS" step and tries to reconnect indefinitely.
  5. Hi, thanks for your support. Unfortunately it does not work: I set up 9.9.9.9 for all interfaces using NetworkManager. I also deleted .config/eddie/default.profile $ resolvectl Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Current DNS Server: 9.9.9.9#dns.quad9.net Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google Link 2 (enp12s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6 Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 9.9.9.9 DNS Servers: 9.9.9.9 192.168.0.1 2606:4700:4700::1111 2a02:8070:d483:bf20:2e00:abff:fe88:c64 Default Route: yes Link 4 (wlan0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Default Route: no Then I used Eddie to connect (as you mention, regardless of Network Lock, so I did not lock this time): $ resolvectl Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: foreign Current DNS Server: 10.128.0.1 DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google Link 2 (enp12s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6 Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 10.128.0.1 DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no Link 4 (wlan0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no Link 5 (Eddie) Current Scopes: DNS Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 10.128.0.1 DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no Then I exit Eddie: $ resolvectl Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Current DNS Server: 10.128.0.1 DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google Link 2 (enp12s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6 Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: fd7d:76ee:e68f:a993::1 DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: yes Link 4 (wlan0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no Here I do not have resolving. Eddie did not reinstate 9.9.9.9 to my interfaces. If I restart systemd-resolved: $ sudo systemctl restart systemd-resolved $ resolvectl Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google Link 2 (enp12s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6 Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 9.9.9.9 DNS Servers: 9.9.9.9 192.168.0.1 2606:4700:4700::1111 2a02:8070:d483:bf20:2e00:abff:fe88:c64 Default Route: yes Link 4 (wlan0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no this works again. This suggests a bug when Eddie handles stub based systemd-resolved configuration, no? Could Eddie simply restart systemd-resolved at exit? It has root permission. Would it be a possible solution?
  6. AmneziaWG was recently introduced to Eddie Android. It can be surmised that it will find its way into all other clients, too, in the coming months. I don't think another protocol will come so quickly. Please experiment with AmneziaWG first. Besides, all proxy protocols are being shot down, like Shadowsocks. Further protocols like V2Ray were proposed, but since they're all proxy protocols, they will never be implemented. AmneziaWG, on the other hand, is Wireguard essentially, so it got attention.
  7. Hello! The IPv6 networks are up and all the servers are operating normally. Kind regards
  8. @Staff Any updates on this?
  9. now it's open-source... plans to add? //Unlike those conventional VPN protocols, TrustTunnel is engineered to blend in with regular HTTPS traffic, making it far harder to throttle or block and helping it slip past deep-packet inspection, all while preserving strong privacy and security. It achieves this through TLS-based encryption, the same standard that secures HTTPS, and by leveraging HTTP/2 or HTTP/3 transport, which are ubiquitous on the web. Each connection runs on its own dedicated stream, which combines packets for faster, more efficient transmission. It is also optimized for mobile platforms and performs well even in unstable network conditions.
  10. Thanks for quick response! Glad to know you are on it
  11. Hello! Yes, all the IPv6 networks of all the servers in Alblasserdam are 100% down, therefore the system detects high packet loss. IPv4 infrastructure is fine at the moment. We have contacted the datacenter and we are waiting for a check and if possible an expedite solution. If this is not feasible, we will determine whether to reopen the Alblasserdam servers exclusively with IPv4 or not. Amsterdam infrastructure is not affected, different datacenter and different providers. Kind regards
  12. 90% of the NL servers have disappeared from the Eddie Client. 2 remain currently. I did see that almost all of them had low packet loss notification prior to disappearing. More just a post for visibility of the issue than anything else.
  13. @zebulon Hello! Please note that Network Lock has nothing to do with DNS settings. Now, the problem seems here: In other words, the previous DNS setting for wlan0 were 10.128.0.1 and fd7d:76ee:e68f:a993::1 according to Eddie. So it's possible that Eddie restores the system DNS settings as expected, but with the same VPN DNS, even for /etc/resolv.conf. Somehow in a previous session the proper DNS settings were not restored and Eddie takes (now correctly, the error must have occurred in a previous session) those settings as the original system settings in subsequent sessions. Please try this: set all the correct DNS (globally and for each interface) while Eddie is not running, delete Eddie configuration file ~/.config/eddie/default.profile, make sure that only WiFi or only Ethernet is connected, re-start Eddie and try again. Kind regards
  14. Note I am happy to provide logs, but while performing tests it seems to be stuck until I restart systemd-resolved. So I am afraid the log itself is tainted. that said, here you can find it attached: eddie-log-20260123.txt
  15. Hi, I have an issue after I switched from manual mode to stub mode using systemd-resolved. My /etc/resolv.conf file is a symlink to /run/systemd/resolve/stub-resolv.conf as described in https://wiki.archlinux.org/title/Systemd-resolved#DNS. Before I run eddie-ui v2.24.6, my resolvectl status shows: $ resolvectl Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google Link 2 (enp12s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6 Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.0.1 DNS Servers: 192.168.0.1 2a02:8070:d483:bf20:2e00:abff:fe88:c64 Default Route: yes Link 4 (wlan0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Default Route: no 192.168.0.1 is the address of my router, which uses my ISP DNS (I know, I should fix this...) If I activate Network Lock, I get: Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google Link 2 (enp12s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6 Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.0.1 DNS Servers: 192.168.0.1 2a02:8070:d483:bf20:2e00:abff:fe88:c64 Default Route: yes Link 4 (wlan0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no Note it changes the DNS for Link 4 (wlan0), wlthough Wifi is deactivated on that machine (I use wired Ethernet, plugged to the router). I can deactivate Network lock and connect to the Internet again. However, if I join a VPN server (connect to a recommended server): Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: foreign Current DNS Server: fd7d:76ee:e68f:a993::1 DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google Link 2 (enp12s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6 Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 10.128.0.1 DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no Link 4 (wlan0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no Link 6 (Eddie) Current Scopes: DNS Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 10.128.0.1 DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no I can access Internet, my DNS is then 10.128.0.1. The problem occurs when I exit Eddie-ui, or if I disconnect to network and unlock Network lock. Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Current DNS Server: fd7d:76ee:e68f:a993::1 DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google Link 2 (enp12s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6 Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 10.128.0.1 DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: yes Link 4 (wlan0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no Here Link2 still has 10.128.0.1 as DNS server, but I am blocked because I am disconnected from the VPN server. Only a restart of systemd-resolved allows me to return to correct DNS: $ sudo systemctl restart systemd-resolved $ resolvectl Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google Link 2 (enp12s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6 Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.0.1 DNS Servers: 192.168.0.1 2a02:8070:d483:bf20:2e00:abff:fe88:c64 Default Route: yes Link 4 (wlan0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.128.0.1 fd7d:76ee:e68f:a993::1 Default Route: no Interestingly, if before I restart systemd-resolved I run Eddie-ui again, if I try to activate the network lock then it is stuck with "Activate Network lock via nftables". I am unsure if this is related. It seems there is an issue on my system where Edie cannot reinstate DNS properly. Any idea? Am I doing something wrong?
  16. Hello! You can modify this behavior in Eddie's "Preferences" > "DNS" window. Kind regards
  17. While this does allow my containers to run, Eddie forces Docker's DNS to be funneled through the VPN tunnel by default: ollama 23-01-2026 0:05:42 $ docker exec -it openwebui /bin/bash root@cbc2b35dbaf3:/app/backend# cat /etc/resolv.conf # Generated by Docker Engine. # This file can be edited; Docker Engine will not make further changes once it # has been modified. nameserver 10.24.198.1 # Based on host file: '/etc/resolv.conf' (legacy) # Overrides: [] root@cbc2b35dbaf3:/app/backend# exit exit ollama 23-01-2026 0:07:23 $ ifconfig tun0 tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 10.24.198.90 netmask 255.255.255.0 destination 10.24.198.90 inet6 fe80::dd69:3985:9114:816a prefixlen 64 scopeid 0x20<link> inet6 fde6:7a:7d20:14c6::1058 prefixlen 64 scopeid 0x0<global> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC) RX packets 6733 bytes 3810080 (3.8 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 6667 bytes 1138370 (1.1 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 As a result, docker containers can't resolve each other's names anymore. This isn't very useful as docker compose stacks often need that internal DNS to talk to each other.
  18. Last week
  19. .. don't look at me I've never run OPNsense, and so never read the linked guide, so there's no experience to draw ideas from.. sorry!
  20. Loving these new speedy servers! Would love to see some upgrades to the 2 overworked connections in Montreal.
  21. Every time a VPN connection is started, there is a chance Eddie will crash, most often by the third connection attempt. Here, I just tapped on the same server (but it could be any server) three times, then Eddie quit and the VPN disconnected. This doesn't happen with Eddie 3.3.0. https://eddie.website/report/46708ecc/
  22. Hey, digging down I think that there's a issue somewhere with ICMPv6, when doing "curl -6 ifconfig.me" I get the correct response, AirVPN IP, here's the packet : Interface Protocol Source Destination WG_INT TCP [fd7d:76ee:e68f:a993:XXXX:XXXX:XXXX:XXXX]:7263 [2600:XXXX:X:XXXX::]:80 when doing "curl -6 https://ipleak.net/json/" on the other hand, gives me no results, and the packet has the same source as dest address: Interface Protocol Source Destination WG_INT ICMPv6 fd7d:76ee:e68f:a993:XXXX:XXXX:XXXX:XXXX fd7d:76ee:e68f:a993:XXXX:XXXX:XXXX:XXXX WG_INT ICMPv6 fd7d:76ee:e68f:a993:XXXX:XXXX:XXXX:XXXX fd7d:76ee:e68f:a993:XXXX:XXXX:XXXX:XXXX WG_INT ICMPv6 fd7d:76ee:e68f:a993:XXXX:XXXX:XXXX:XXXX fd7d:76ee:e68f:a993:XXXX:XXXX:XXXX:XXXX WG_INT ICMPv6 fd7d:76ee:e68f:a993:XXXX:XXXX:XXXX:XXXX fd7d:76ee:e68f:a993:XXXX:XXXX:XXXX:XXXX (the packet is repeatedly sent without any response or result..) I've followed the community guide and set up correctly the whole thing but it's not working, If you have an idea, Have a great day! @OPN-UserGuide @Staff @Tech Jedi Alex
  23. Hello! Thank you very much for your tests. If you don't want to rely on a free VPN, you may also use a configuration file generated by our Configuration Generator, needed only for the first time. You'll need access to one of the AirVPN websites. If you cannot reach the main website, feel free to open a ticket to receive mirror addresses. Kind regards
  24. finally managed to connect via my phone, thanks to New app version. If you are located in .Ru just use any free working vpn to reach airvpn server to log in, than disconnect and use airvpn. For me worked amnezia with default parameters. Thanks staff for your work.
  25. Thanks for your reply. Glad to see I am not the only one. What cpu do you happen to have if I may ask? It seems to work for some people on those distros for some reason. I was affraid of that also, might have to wait for a long time for that to change. What are distros you had luck with? In EndeavorOS it works flawlessly. I have an old AMD FX cpu. MX Linux and Q4OS had that laggy UX.
  26. Wrong forums. The answer is always YES, of course. That is possible; please open a ticket and kindly ask for a three-day trial.
  27. Hi! I recently heard about AirVPN, and how it differs from other VPNs by not having logs, etc.However, I already use a VPN service, and I wanted to know if it would be worthwhile to switch to AirVPN. I also wanted to know if a free trial would be possible; a few days would be helpful, just to see if it's worth it. Thanks in advance!
  28. thank you for going the extra mile, albeit it does not work like a charm on LineageOS 23. Tested different values with Wireguard and AmneziaWG - with or without CPS. It leaks my IP via WebRTC. Hello! Thank you very much for your tests! WebRTC is managed by the browser. It is aimed at connecting directly to remote peers through STUN, NAT traversing or other methods all involving the ability to bypass the VPN tunnel (provided that the routing table has preserved the original default gateway). On desktop systems any leak can be prevented by firewall rules (Network Lock) while on Android (where we do not have privileges to manage a firewall) you should enable both "Always on VPN" and "Block traffic if VPN is inactive" for Eddie. These options must prevent any possible leak. Disabling WebRTC on the browser, if you don't need it, is also a more specific solution and an additional layer of defense. Lineage OS 23 is built over Android 16. The latest Android versions only allow notifications to be enabled at the express choice of the user and not the app. Eddie should have shown this message: Please note, in case the current Android security policy does not allow this setting to be changed from within this app, you explicitly need to change it from the Android system settings panel. Also please note, in case notifications are not enabled, Eddie will not work properly. Kind regards
  29. Hello! We think that the problem is on your side. Castula is absolutely perfect just like other servers you experience this problem on. We have no complaints whatsoever about any of the servers you mention. Note that Castula, Chamukuy, and Elgafar are all connected to the same upstream in the same small subnet. Your tests have been instrumental to make us aware of the problem (SYN flood and similar events) frequently occurring on specific Canadian servers, so thank you! A good thing you can do on your side is black listing the servers that don't work well for you. You have anyway a vast range to pick from. Keep us informed if the problem suddenly appears on one or more of the servers that are perfectly fine for you now. Kind regards
  1. Load more activity
×
×
  • Create New...