Not connected, Your IP: 216.73.216.173
Online: 42566 users - 468623 Mbit/s total BWAll Activity
This stream auto-updates
- Past hour
-
-
-
-
-
-
-
- Today
-
-
-
- Yesterday
-
-
-
-
HowTo: OPNsense using Wireguard with IPv6 support
twistabled4alt replied to OPN-UserGuide's topic in How-To
Thank you for your reply. Could you please elaborate on how you can achieve ipv6 out only using ipv4 to connect to the vpn tunnel? And do you think I could keep my ISP ipv6 for normal browsing?? Thx -
-
@taikeru Hello! Thank you for your great feedback about the Suite software, much appreciated by the development guys too. Provided that the desktop user is in the airvpn group, the usage you mention should be possible with some caveat, as cuckoo needs a tty. Can you please add the following line to the .desktop file: terminal=true and test again? Kind regards
-
-
Hello! We are glad to announce that Eddie 2.26.0 beta has been released and is now available for public testing. This release is mostly about maintenance, security fixes, and compatibility work. It includes several security hardening changes, updates to OpenVPN 2.7.3 and WireGuard for Windows 1.0, improved OpenVPN driver handling on Windows, and a general cleanup of old or unused code paths. To test it: Go to the download page for your operating system. Click “Switch to EXPERIMENTAL”. Download and install Eddie 2.26.0 beta. Eddie 2.26.0 beta is available for Windows, Linux, and macOS. We are also continuing the larger work of modernizing Eddie Desktop, also with a new modern UI. We know that many requested features are still waiting, including dark mode, split tunneling, Amnezia support, and more. They are not forgotten. For this release, the focus was on fixes and updates that needed to reach users first. We expect this beta to move to stable soon. Thank you for testing, and as always for your support. Main changelog: Version 2.26.0 (Mon, 29 Jun 2026 14:29:16 +0000) [change] [all] Updated the app to .NET 10 [change] [all] Updated the legacy interface to .NET Framework 4.8.1 [change] [windows] Removed Windows 7 support [fix] [all] Cleaned WireGuard configuration generation by removing unsupported entries [change] [windows] Improved OpenVPN driver setup and adapter management on Windows [change] [windows] Removed outdated Windows driver options [change] [windows] Removed the old Windows Firewall Network Lock mode and migrated existing profiles. [change] [linux/macos/bsd] Removed unused filesystem protection handling from the elevated helper. [change] [all] Restricted elevated helper tool discovery to trusted application folders. [change] [all] Added limits to elevated helper replies to protect client memory use. [change] [all] Removed the Tor control cookie path option [fix] [all] Various security hardening fixes [fix] [windows] Fixed Windows elevated launches with long command lines [change] [windows] Improved Windows elevated argument handling to prevent extra arguments from being injected into helper tools [fix] [windows] Fixed Windows OpenVPN routing with TAP adapters [change] [windows] Updated WireGuard for Windows to version 1.0 [change] [all] Updated OpenVPN to 2.7.3 [fix] [linux] Fixed Linux AppImage cleanup. Credits GitHub #147 and #152. Thanks to ThienBienBlue. [fix] [linux] Fixed Network Lock detection on clean systems where optional nftables or iptables tools are not installed. [change] [all] Removed custom OpenVPN and Hummingbird executable path options. [change] [linux] Removed the Linux dependency on the system ICU library [change] [all] Misc fixes and general cleanup Kind regards & datalove AirVPN Staff
- ...
-
- 1
-
-
.thumb.png.8be84fd39f94c1640ac8c5456fbf3449.png)
@Kiki09 Hello! You need to set FIREWALL_VPN_INPUT_PORTS environment variable, otherwise container's firewall blocks all incoming packets on the virtual network interface. Please check the manual https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/airvpn.md VPN_PORT_FORWARDING_LISTENING_PORTS has a quite different purpose. It sets up a redirection of incoming traffic from the VPN opened port to a custom localhost port of your choosing. As the GlueTun manual clearly warns, do not use this with torrent clients, or any other software that publicly announces its port, as that software would not be aware of the publicly visible port and would be announcing the private port instead (you can see more details of this explanation on our FAQ answer about p2p). Furthermore, it does not even instruct the firewall to allow incoming packets on the virtual network interface. Kind regards -
Port Forwarding Stopped Working?
theradgrad replied to theradgrad's topic in Troubleshooting and Problems
Further testing reveals no pattern as to when it works and when it doesn't (95% of the time it doesn't work). Below are the command outputs for the ones suggested by Staff. I had to adjust some slightly as behavior differs between Linux/FreeBSD (what I presume the commands may be for) and OpenBSD. $ netstat -an -f inet Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address TCP-State tcp 0 64 192.168.1.181.22 192.168.1.187.53299 ESTABLISHED tcp 0 0 *.22 *.* LISTEN tcp 0 0 127.0.0.1.25 *.* LISTEN Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address udp 0 0 10.xxx.xxx.xxx.33179 172.234.25.10.123 udp 0 0 10.xxx.xxx.xxx.28723 66.244.16.123.123 udp 0 0 10.xxx.xxx.xxx.3525 166.88.142.52.123 udp 0 0 10.xxx.xxx.xxx.15687 72.14.186.59.123 udp 0 0 *.42358 *.* udp 0 0 *.9248 *.* udp 0 0 *.* *.* udp 0 0 *.* *.* udp 0 0 192.168.1.181.68 *.* Sadly, none of the ports I have forwarded (XXXXX/YYYYY/ZZZZZ) come up in the output. OpenBSD doesn't natively have sockstat, but I was able to find a similar script on GitHub Gist (also attached). $ chmod +x ~/Downloads/sockstat && doas ~/Downloads/sockstat USER CMD PID MOUNT MODE ADDR _slaacd slaacd 30811 internet6 udp *:0 root slaacd 1097 internet6 udp *:0 root openvpn 27593 internet udp *:42358 _dhcp dhcpleased 13172 internet udp 192.168.1.181:68 _smtpd smtpd 24634 internet tcp 127.0.0.1:25 theradgrad run-server 59906 internet udp *:XXXXX root dhcpleased 78891 internet udp *:0 root sshd 88044 internet6 tcp *:22 XXXXX does appear in this list (although YYYYY and ZZZZZ do not). $ doas netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 192.168.1.1 UGS 0 13 - 8 bge0 0/1 10.xxx.xxx.1 UGS 1 23 - 8 tun0 128/1 10.xxx.xxx.1 UGS 5 48 - 8 tun0 224/4 127.0.0.1 URS 0 0 32768 8 lo0 10.xxx.xxx/24 10.xxx.xxx.1 UGS 0 0 - 8 tun0 10.xxx.xxx.1 10.xxx.xxx.xxx UHh 3 3 - 8 tun0 10.xxx.xxx.xxx 10.xxx.xxx.xxx UHl 0 46680 - 1 tun0 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1 2 32768 1 lo0 192.168.1/24 192.168.1.181 UCn 2 1467 - 4 bge0 192.168.1.1 xx:xx:xx:xx:xx:xx UHLch 2 364 - 3 bge0 192.168.1.181 xx:xx:xx:xx:xx:xx UHLl 0 119221 - 1 bge0 192.168.1.187 xx:xx:xx:xx:xx:xx UHLc 3 707 - 3 bge0 192.168.1.255 192.168.1.181 UHb 0 0 - 1 bge0 204.8.98.32/32 192.168.1.1 UGS 1 1 - 8 bge0 Internet6: Destination Gateway Flags Refs Use Mtu Prio Iface ::/3 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1 UGS 0 0 - 8 tun0 ::/96 ::1 UGRS 0 0 32768 8 lo0 ::1 ::1 UHhl 10 20 32768 1 lo0 ::ffff:0.0.0.0/96 ::1 UGRS 0 0 32768 8 lo0 2000::/4 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1 UGS 1 29 - 8 tun0 2002::/24 ::1 UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1 UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1 UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1 UGRS 0 0 32768 8 lo0 3000::/4 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1 UGS 0 0 - 8 tun0 fc00::/7 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1 UGS 0 0 - 8 tun0 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:/64 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1001 UCn 1 0 - 4 tun0 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:/64 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1001 UGS 0 0 - 8 tun0 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1 link#0 UHch 4 8 - 3 tun0 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1001 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1001 UHhl 1 11 - 1 tun0 fe80::/10 ::1 UGRS 0 2 32768 8 lo0 fec0::/10 ::1 UGRS 0 0 32768 8 lo0 fe80::1%lo0 fe80::1%lo0 UHl 0 0 32768 1 lo0 fe80::%tun0/64 fe80::xxxx:xxxx:xxxx:xxxx%tun0 Un 0 0 - 4 tun0 fe80::xxxx:xxxx:xxxx:xxxx%tun0 fe80::xxxx:xxxx:xxxx:xxxx%tun0 UHl 0 0 - 1 tun0 ff01::/16 ::1 UGRS 0 3 32768 8 lo0 ff01::%lo0/32 fe80::1%lo0 Um 0 1 32768 4 lo0 ff01::%tun0/32 fe80::xxxx:xxxx:xxxx:xxxx%tun0 Um 0 1 - 4 tun0 ff02::/16 ::1 UGRS 0 3 32768 8 lo0 ff02::%lo0/32 fe80::1%lo0 Um 0 1 32768 4 lo0 ff02::%tun0/32 fe80::xxxx:xxxx:xxxx:xxxx%tun0 Um 0 2 - 4 tun0 No XXXXX/YYYYY/ZZZZZ here. $ doas tcpdump -ni tun0 tcp port XXXXX tcpdump: listening on tun0, link-type LOOP ^C 829 packets received by filter 0 packets dropped by kernel I started the packet capture for XXXXX, then tried connecting to the server externally (failed), then SIGINTed the capture process. Strangely, no packets were dropped. YYYYY and ZZZZZ (these should only be accessible externally) both show a bunch of traffic when connecting externally, which seems work significantly more reliably. External port checks on those also show traffic upon each check (but still claim to be closed). Thank you sockstat - Last week
-
-
Port Forwarding Stopped Working?
theradgrad replied to theradgrad's topic in Troubleshooting and Problems
Hello, thank you for replying and demystifying more details for me. I started running through the commands you listed and I think I may have discovered what the problem was (EDIT: probably not, see bottom). I was running my one server binary through an SSH session, which I could've sworn I've done without any issues (maybe I only thought it was okay because of using the host's local IP in those instances), but running it in a terminal window on the host itself seemed to completely resolve the issue. I figure this is a default security measure of OpenBSD which is honestly for the better. As for the other two forwarded ports, they seem to be working perfectly, despite still receiving those strange TCP RSTs through AirVPN's Web-based port checker and on other various port checking sites. Thank you for all of the guidance and helping me look in just the right places for me to figure out the issue. Cheers! If you or anyone else would still like me to post the command outputs, feel free to reply and ask me. EDIT: Never mind, I celebrated too quickly. I temporarily closed the server binary and reopened it, and now I'm back to square one. I'm currently investigating further. EDIT 2: A system restart got it working again. The only change I made to my system in between then was updating something unrelated in FVWM and relaunching that, but maybe it then leading to a different X11 process caused further issues (I'm still fairly new to OpenBSD). Anyway, seems okay now...only time will tell. EDIT 3: It stopped working again. The openvpn connection was up (uninterrupted) and the server binary was up (uninterrupted), it worked just fine initially, then I tried it a second time and it won't work anymore. Investigating some more. -
-
hello, i've been tinkering with the AirVPN suite for a bit now on Artix Linux (openRC), and so far everything is pretty painless to set up. (immense thanks to the airvpn team for this software suite, it's very nice) i do have a question about cuckoo, though, as it seems to be a bit touchy with being launched via desktop file (via Exec line) or as a child of another (i.e. putting cuckoo -r "%command%" in a Steam game launch parameters). is this behavior supported? i'm perhaps missing something reading the documentation, but it is a little sparse about how cuckoo can be used and to what extents it will not work. testing has shown to me that via terminal, cuckoo -r "<command>" seems to work as expected (i've added my user to the airvpn group) but via .desktop file, any permutation of the launch command seems to launch cuckoo, as it does show the cuckoo version banner (when launched via gio or gtk-launch) but it does not seem to receive the rest of the args from Exec and will not launch the given command Exec=cuckoo -r "<command>" Exec="cuckoo -r <command>" Exec=cuckoo -r \"<command>\" this is more of a nitpick, as i've got no problem writing a couple of wrapper scripts for apps that i need tunneled outside of AirVPN, so i'm more interested in the details. i would like to know if it is or will ever be supported though, as it would be nice to have something along the lines of a mullvad-exclude %command% syntax for Steam game launch parameters that would allow me to test specific games off the VPN (and maybe for competitive games, where i'd rather not have a major spike in ping)
-
Maybe unrelated but thought I would put this out here since I have seen a few differences in my Mint systems for the past week or so. When mounting Eddie on linux mint it used to be crisp and fast then perfect. Now it just hangs on "connecting" and after 45 seconds it disconnects and goes back to connecting again. Second time its very fast and smooth performance, rock solid all day long. Just never had this happen before recently. I have done no homework under the hood this is a simple mention in case some reading through are seeing the same thing. Using Eddie stable - fyi.
-
Hi everyone, I'm currently setting up a media server stack (the "Arr" suite) on a Linux (Ubuntu Server) VM hosted on Proxmox. I'm struggling with seeding: my downloads work perfectly, but my upload speed is constantly at 0 B/s, even for high-demand torrents like the Ubuntu ISO. I am using Gluetun as a sidecar for qBittorrent with AirVPN (WireGuard). Environment: Host: Proxmox (Linux VM - Ubuntu Server) VPN Provider: AirVPN (WireGuard) Setup: Gluetun -> qBittorrent (network_mode: service:gluetun) Port Forwarding: Port 7755 is configured in the AirVPN client area and mapped in Gluetun. Configuration (docker-compose.yml): services: gluetun: image: qmcgaw/gluetun container_name: gluetun cap_add: - NET_ADMIN devices: - /dev/net/tun:/dev/net/tun environment: - VPN_SERVICE_PROVIDER=airvpn - VPN_TYPE=wireguard - WIREGUARD_PRIVATE_KEY=${AIRVPN_WG_PRIVATE_KEY} - WIREGUARD_PRESHARED_KEY=${WIREGUARD_PRESHARED_KEY} - WIREGUARD_ADDRESSES=${AIRVPN_WG_ADDRESS} - SERVER_COUNTRIES=Netherlands - VPN_PORT_FORWARDING_LOCAL_PORT=7755 - TZ=${TZ} - FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24 ports: - 8080:8080 - 7476:7476 - 8191:8191 - 7755:7755/tcp - 7755:7755/udp volumes: - ${CONFIG_DIR}/gluetun:/gluetun restart: unless-stopped qbittorrent: image: lscr.io/linuxserver/qbittorrent:latest container_name: qbittorrent network_mode: service:gluetun environment: - PUID=${PUID} - PGID=${PGID} - TZ=${TZ} - WEBUI_PORT=8080 volumes: - ${CONFIG_DIR}/qbittorrent:/config - ${DATA_DIR}:/data restart: unless-stopped What I have already verified: AirVPN Dashboard: Port 7755 is active and assigned to my current WireGuard server. qBittorrent Settings: Port is set to 7755, uTP is enabled, global upload limits are unlimited. Internal Connectivity: Downloads work at full speed (10+ MiB/s), confirming the VPN tunnel is functional. Logs: No obvious errors in Gluetun; the WireGuard tunnel initializes correctly. The Issue: Despite these settings, I have 0 incoming connections and 0 upload speed. External port checkers report the port as CLOSED. When monitoring the peer list in qBittorrent, I occasionally see peers attempting to connect, but they disconnect almost immediately. It seems that while I can download (the swarm can see me), external peers cannot establish a stable incoming connection to initiate a handshake. I am testing on private trackers, and I am aware that my 200 Mbps upload speed often gets outrun by dedicated seedboxes with superior peering. However, even when testing with the Ubuntu ISO (a high-demand public torrent), I observe zero incoming connections and no upload activity. This strongly suggests a deeper network configuration issue preventing peers from initiating a handshake with my container. Could this be a routing issue at the Gluetun level, or perhaps a Proxmox/VM network bridge setting that is dropping incoming packets on the forwarded port? Any help or guidance on further debugging (iptables, routing tables, etc.) would be greatly appreciated. Thanks in advance ! -
-
-
-
Apologies if this is obvious or has been answered before, but I was unable to find what I was looking for online or in the forums. I can verify the SHA and MD5 sums for the RPM package just fine, but how can I verify via the supplied key? Even after importing the key trying to verify the signature of the RPM package fails. I'm not the best with RPM so I'm likely missing something obvious, but any help would be greatly appreciated. Thanks! ~ $ sudo rpm --import https://eddie.website/repository/keys/eddie_maintainer_gpg.key -vvv D: loading keyring from rpmdb D: opening db index /usr/lib/sysimage/rpm/Packages.db mode=0x0 D: opening db index /usr/lib/sysimage/rpm/Index.db mode=0x0 D: opening db index Name tag=1000 D: opening db index Basenames tag=1117 D: opening db index Group tag=1016 D: opening db index Requirename tag=1049 D: opening db index Providename tag=1047 D: opening db index Conflictname tag=1054 D: opening db index Obsoletename tag=1090 D: opening db index Triggername tag=1066 D: opening db index Dirnames tag=1118 D: opening db index Installtid tag=1128 D: opening db index Sigmd5 tag=261 D: opening db index Sha1header tag=269 D: opening db index Filetriggername tag=5069 D: opening db index Transfiletriggername tag=5079 D: opening db index Recommendname tag=5046 D: opening db index Suggestname tag=5049 D: opening db index Supplementname tag=5052 D: opening db index Enhancename tag=5055 D: read h# 1179 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-f3f033b1-5d5e777a to keyring D: read h# 8133 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-1abd1afb-450ef738 to keyring D: read h# 40293 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-66de8ddf-5811982a to keyring D: added subkey 0 of main key gpg-pubkey-66de8ddf-5811982a to keyring D: added subkey 1 of main key gpg-pubkey-66de8ddf-5811982a to keyring D: read h# 74820 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-287a0027-682477e3 to keyring D: read h# 97570 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-3fa1d6ce-67c856ee to keyring D: read h# 97571 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-39db7c82-66c5d91a to keyring D: read h# 97572 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-09d9ea69-68595a8c to keyring D: read h# 97680 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-29b700a4-6a17fa38 to keyring D: read h# 101022 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-8a239aec-69833e8e to keyring D: added subkey 0 of main key gpg-pubkey-8a239aec-69833e8e to keyring D: closed db index Enhancename D: closed db index Supplementname D: closed db index Suggestname D: closed db index Recommendname D: closed db index Transfiletriggername D: closed db index Filetriggername D: closed db index Sha1header D: closed db index Sigmd5 D: closed db index Installtid D: closed db index Dirnames D: closed db index Triggername D: closed db index Obsoletename D: closed db index Conflictname D: closed db index Providename D: closed db index Requirename D: closed db index Group D: closed db index Basenames D: closed db index Name D: closed db index /usr/lib/sysimage/rpm/Index.db D: closed db index /usr/lib/sysimage/rpm/Packages.db ~ $ sudo rpm -Kvv eddie-ui_2.24.6_linux_x64_opensuse.rpm D: loading keyring from rpmdb D: opening db index /usr/lib/sysimage/rpm/Packages.db mode=0x0 D: opening db index /usr/lib/sysimage/rpm/Index.db mode=0x0 D: opening db index Name tag=1000 D: opening db index Basenames tag=1117 D: opening db index Group tag=1016 D: opening db index Requirename tag=1049 D: opening db index Providename tag=1047 D: opening db index Conflictname tag=1054 D: opening db index Obsoletename tag=1090 D: opening db index Triggername tag=1066 D: opening db index Dirnames tag=1118 D: opening db index Installtid tag=1128 D: opening db index Sigmd5 tag=261 D: opening db index Sha1header tag=269 D: opening db index Filetriggername tag=5069 D: opening db index Transfiletriggername tag=5079 D: opening db index Recommendname tag=5046 D: opening db index Suggestname tag=5049 D: opening db index Supplementname tag=5052 D: opening db index Enhancename tag=5055 D: read h# 1179 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-f3f033b1-5d5e777a to keyring D: read h# 8133 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-1abd1afb-450ef738 to keyring D: read h# 40293 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-66de8ddf-5811982a to keyring D: added subkey 0 of main key gpg-pubkey-66de8ddf-5811982a to keyring D: added subkey 1 of main key gpg-pubkey-66de8ddf-5811982a to keyring D: read h# 74820 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-287a0027-682477e3 to keyring D: read h# 97570 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-3fa1d6ce-67c856ee to keyring D: read h# 97571 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-39db7c82-66c5d91a to keyring D: read h# 97572 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-09d9ea69-68595a8c to keyring D: read h# 97680 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-29b700a4-6a17fa38 to keyring D: read h# 101022 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-8a239aec-69833e8e to keyring D: added subkey 0 of main key gpg-pubkey-8a239aec-69833e8e to keyring eddie-ui_2.24.6_linux_x64_opensuse.rpm: Header V4 RSA/SHA512 Signature, key ID 400d7698: NOKEY Header SHA256 digest: OK Header SHA1 digest: OK Payload SHA256 digest: OK V4 RSA/SHA512 Signature, key ID 400d7698: NOKEY MD5 digest: OK D: closed db index Enhancename D: closed db index Supplementname D: closed db index Suggestname D: closed db index Recommendname D: closed db index Transfiletriggername D: closed db index Filetriggername D: closed db index Sha1header D: closed db index Sigmd5 D: closed db index Installtid D: closed db index Dirnames D: closed db index Triggername D: closed db index Obsoletename D: closed db index Conflictname D: closed db index Providename D: closed db index Requirename D: closed db index Group D: closed db index Basenames D: closed db index Name D: closed db index /usr/lib/sysimage/rpm/Index.db D: closed db index /usr/lib/sysimage/rpm/Packages.db
-
Port Forwarding Stopped Working?
Staff replied to theradgrad's topic in Troubleshooting and Problems
@theradgrad Hello! The fact that the host is sending a RST strongly suggests the packet is making it through PF and reaching the TCP stack, where no matching listening socket exists for that specific destination IP and port. The port tester does not test UDP, only TCP. Please ascertain whether the listening program is really listening to all interfaces with: netstat -an -f inet Look specifically for something like 0.0.0.0:YYYYY or VPN_IP:YYYYY If instead it shows 127.0.0.1:YYYYY or LAN_IP:YYYYY then the kernel will immediately send RSTs for packets addressed to the VPN IP. Also, please send the output of the following commands: sudo sockstat -4 -l sudo netstat -rn Finally, a simultaneous packet capture while reproducing the issue: sudo tcpdump -ni tun0 tcp port YYYYY Kind regards -
Port Forwarding Stopped Working?
theradgrad replied to theradgrad's topic in Troubleshooting and Problems
Hi, thank you for the reply. In the AirVPN web interface, I only see that for TCP connections, but never for any UDP ones (regardless of that, though, none of them work unfortunately). Here's an example of one of my forwarded ports that uses both: Yes, I just confirmed it now. bge0 is the name of my physical NIC and tun0 is OpenVPN's virtual NIC: $ ifconfig lo0: flags=2008049<UP,LOOPBACK,RUNNING,MULTICAST,LRO> mtu 32768 index 3 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 bge0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500 lladdr xx:xx:xx:xx:xx:xx index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.1.181 netmask 0xffffff00 broadcast 192.168.1.255 enc0: flags=0<> index 2 priority 0 llprio 3 groups: enc status: active pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136 index 4 priority 0 llprio 3 groups: pflog tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 index 14 priority 0 llprio 3 groups: tun status: active inet 10.xxx.xxx.xxx --> 10.xxx.xxx.1 netmask 0xffffff00 inet6 fe80::xxxx:xxxx:xxxx:xxxx%tun0 --> prefixlen 64 scopeid 0xe inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1001 --> prefixlen 64 Here's a copy of my pf.conf (with some irrelevant data stripped for privacy/security), if that helps: # Define macros: ext_if = "bge0" # Ethernet interface (physical) vpn_if = "tun0" # OpenVPN interface (virtual) # Don't filter on loopback interfaces: set skip on lo # Scrub incoming packets: match in all scrub (no-df random-id) # Modify incoming IPv4 packets of all protocols (TCP, UDP, ICMP, etc.) over all # interfaces (excl. loX) in order to remove their "don't fragment" bit, and to # randomize their IP identification field in the event it's set to zero. May # help in situations where weird NFS implementations send fragmented packets # containing "don't fragment" bits, and where annoying OSes send zero IP ID # fields. It _may_ cause HTTPS to break, as noted here: # https://serverfault.com/questions/412083 # Honestly, not entirely sure what it does, but it sounds okay I suppose... # Block everything by default: block # Enforce antispoofing measures: block in quick from urpf-failed # https://dylanharris.org/blog/2017/b28.shtml # All data leaving the internal network must go through tun0, and never outside # it, so as per the above article this should be enabled. # Whitelist incoming protocol/port connections over bge0: pass on $ext_if proto {tcp udp} from $ext_if:network to $ext_if port {22 XXXXX} # XXXXX is a forwarded port that should also be accessible locally (I have # confirmed that it is). pass in on $ext_if proto icmp from $ext_if:network to any pass out on $ext_if proto icmp from any to $ext_if:network # Allow DNS (for server IP lookup): pass quick proto {tcp udp} from any to any port 53 keep state # https://daemonforums.org/showthread.php?t=11666 # Whitelist VPN IP addresses: include "/etc/pf.conf.d/vpn_server_ips.conf" # Generated through the relevant steps mentioned here: # https://airvpn.org/forums/topic/65332-prevent-leaks-with-bsd-pf/ pass in log (to pflog1) on $vpn_if proto {tcp udp} to any port {YYYYY ZZZZZ} pass in log (to pflog1) on $vpn_if proto udp to any port {XXXXX} # YYYYY/ZZZZZ = other forwarded ports (traffic on these ports should only # traverse over AirVPN) pass on $vpn_if all Thanks for linking me to this. Here's what I've determined: >please make sure that the listening program is really running and listening to the correct port, and that it is started only after the VPN connection has been established <Confirmed via access to the server from another device on the local network. Also, the server daemon was started after connecting to AirVPN with openvpn. >if a bind option is available on the listening program settings please make sure that the program binds to the VPN interface and not to the physical network interface <Intentionally left unbound so it broadcasts on all interfaces (desired operation for the server daemon in particular I'm trying to access). I bound it anyway as a test but was still unable to connect externally. >if automatic port mapping options, including UPnP and NAT-PMP, are available on the listening program settings please make sure that they are all disabled <It's unsupported in all of the server daemons I have. >please make sure that no firewall rule blocks incoming packets to the listening program. You need to check while the system is connected to the VPN as some firewall tools change rule set according to the network type the system is connected to <From what I understand of my pf.conf, those connections should not be blocked (I did as much research as I could but may still be mistaken). >if the listening program runs on a machine that's not directly connected to the VPN but shares the connection with another device, remember to forward packets from the tun interface of the device creating the tunnel to the final destination (typical example, a router sharing VPN traffic with all the devices behind it) <My OpenBSD host is connected directly to AirVPN, and it only acts as an external server (ports XXXXX/YYYYY/ZZZZZ) and internal server (ports 22/XXXXX) for a few daemons. Would you happen to know what steps I should try next, or if there are any config files/command outputs that would be beneficial to see? Many thanks -
-
HowTo: OPNsense using Wireguard with IPv6 support
DeepAnger replied to OPN-UserGuide's topic in How-To
Hello, how can I successfully set up ipv6 in my case? I get ipv6 address tracked down from my ISP, so I should remove it? And next how to use ipv6? Thank you really much You don't need IPv6 from your ISP to use IPv6 from or in AirVPN. I use OpenWrt and I disabled the wan6 interface then added a ULA IPv6 server on my LAN interface. I'm sorry that I can't help you more. It took me a few weeks to be able to achieve that under OpenWrt and I'm no specialist of it. Using your ISP IPv6 is just adding a big risk of leaking it. -
Port Forwarding Stopped Working?
Staff replied to theradgrad's topic in Troubleshooting and Problems
@theradgrad Hello! In reality your current error message is connection refused (111). It means in general that the packets were forwarded and reached the destination (your node), but it actively reset the connection via TCP RST. We have also checked in real time on the server you mention and packets are properly forwarded from the correct ports to your VPN IP address:port. Please make sure that tun0 is the correct interface name. If it is, the fact that the packets reach the OpenBSD host and it actively replies with a TCP RST suggests the kernel accepted the packet but decided there was no valid listening socket or the packet didn't belong to an existing connection. Please follow this checklist: https://airvpn.org/forums/topic/66388-port-forwarding/?do=findComment&comment=243305 Kind regards -
-
-
HowTo: OPNsense using Wireguard with IPv6 support
twistabled4alt replied to OPN-UserGuide's topic in How-To
Hello, how can I successfully set up ipv6 in my case? I get ipv6 address tracked down from my ISP, so I should remove it? And next how to use ipv6? Thank you really much -
Hello all, A few years ago I had forwarded some ports through AirVPN's site. It worked just fine and so I left it alone all of this time later. For some reason now, it doesn't seem to be actually forwarding them. I'm using OpenBSD and am connected to AirVPN's servers through openvpn. Port checks fail, connections time out, but the servers I'm running locally have indeed occupied those ports (I can access via its local IP). The firewall (pf) has those ports allowed over tun0. Is there something I'm missing or doing wrong, or is there a tiny chance Helvetios (server in question) has some issues? FWIW I tried reconnecting to AirVPN multiple times in the hopes of reaching a different server, but every single time it connected to Helvetios. Thank you in advance if you can help shed some light on this.
-
-
[Unifi] Able to download but not upload torrents
balanthiel replied to melendowski's topic in Troubleshooting and Problems
Hello! Did you figure this out? I've got a UDM as well, and I'm planning to start setting this up soon myself too. Right now on my qbit server, I just run the Eddie software, but I really want to move this to the UDM. If I figure it out, I'll share what I did. Thanks! -
-
@0bacon Hello! Did the problem get resolved after hardware was repaired and you upgraded to AirVPN Suite 2.1.0? Kind regards
-
ANSWERED No DNS on AirVNP Suit on a Ubuntu Container
Staff replied to Titums's topic in AirVPN Suite
Hello! Thank you for your patience to reply to the numerous questions by the support team on your ticket. We re-publish the outcome here for Kubernetes users' and readers' comfort, and for future reference. Bluetit relies on filesystem-level operation to create the resolv.conf backup. In your setup, /etc/airvpn and /etc/resolv.conf are in different file systems. Therefore Linux kernel will return EXDEV ("cross-device link") error when Bluetit tries to move, via stdlib rename() method, /etc/resolv.conf into /etc/airvpn/ Possible work-around: Have /etc/airvpn and /etc/resolv.conf into the same file system, OR don't allow Bluetit to manage DNS by setting, inside bluetit.rc run control file, this directive: ignorednspush on and let the pod manage the DNS. You will not use anymore VPN DNS, but DNS queries will be tunneled anyway. You can still set your favorite DNS (even VPN DNS, if needed), but you have to set it manually. In a future Bluetit version we'll see how to improve Suite compatibility with Kubernetes (and possibly other environments). Kind regards -
Well I don't know if you are, but personally I don't have a fortinet firewall, so I'm not.
-
-
What a welcome surprise to see Zuboff cited as a bibliography entry in a VPN forum. “Surveillance capitalism’s development is best understood as part of a broader contest with the democratic order—the only institutional framework that poses an existential threat. The democratic order retains the legitimate authority to contradict, interrupt, and abolish surveillance capitalism’s foundational operations. Its distinctive advantages include the power to inspire action and the necessary authority to make, impose, and enforce the rule of law.”, she says in a known essay linked by the Staff. Once you disrupt the democratic order’s operations and replace operations of public interest/government body competence with corporate operations, the existential threat disappears. Yet another compelling reason to oppose the delegation of age verification and ID card databases build-up to private companies. Big corps need governments strong enough to protect their properties and any menace from "we, the people", but weak enough to be corruptible and manipulated... 😪 Always, Seeyabye!
-
Not to be cringe, but the US pricing for bundles on Raid are a lot cheaper than UK, because they are priced exactly the same, but the convertion makes it a lot cheaper for UK users to transfer their account to the US and buy them. Example attached. The issue is, Plarium is detecting my VPN. Any suggestions on a potential fix? My first time trying to use my VPN like this, so I am surprised it's an issue, but I suppose if the IP addresses are registered to AirVPN, or there is a known list of their IPs that is being tracked it may be causing the issue
-
Hello! Since OpenVPN and WireGuard fail too, this is not an Eddie-specific problem. However, an Eddie system report could help us understand what goes wrong. Please see here to send a system report generated by Eddie: Kind regards
-
Hello! Of course. Eddie offers a GUI with a one-click connection button, but the case of firewalld is so special to be a very rare exception requiring manual intervention by the system administrator. We can't allow Eddie to manipulate your system in such a profound way. Note that Eddie will work anyway, but you can't use Network Lock to prevent leaks, because firewalld takes exclusive ownership of the firewall rules (Network Lock is based on firewall rules). And after all, do not underestimate yourself. The steps to fix the situation are very simple and "once and for all". Let's break the steps down: 1. Open a terminal (aka shell or Console or Konsole) from your Desktop Environment 2. Type the following command: sudo nano /etc/firewalld/firewalld.conf 3. You are now inside the "nano" editor, editing the firewalld configuration file with administrator (root) privileges. Move with the cursor arrow keys between the options and enter the following line: NftablesTableOwner=no make sure you press ENTER at the end of the line (so the line stays alone between all the other options, anywhere). 4. Save the file by pressing CTRL + O (keep CTRL pressed, and type O) 5. Exit the editor by pressing CTRL + X 6. Restart firewalld with the command (on the terminal): sudo systemctl restart firewalld Kind regards
