pfillionqc 0 Posted ... (edited) I am using Lubuntu 18.04 and the Eddie client. Everything works perfectly when no firewall rule are present. Can you help me find out what is wrong with my firewall rule? My connection log : . 2020.03.14 22:15:54 - Eddie version: 2.16.3 / linux_x64, System: Linux, Name: Ubuntu 18.04.4 LTS \n \l, Version: Linux Vubuntu 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux, Mono/.Net: 4.6.2 (Debian 4.6.2.7+dfsg-1ubuntu1); Framework: v4.0.30319 . 2020.03.14 22:15:54 - Reading options from /home/verylongvmusername_forsafety/.airvpn/default.xml . 2020.03.14 22:15:54 - Command line arguments (5): path="/home/verylongvmusername_forsafety/.airvpn" path.resources="/usr/share/eddie-ui" path.exec="/usr/bin/eddie-ui" console.mode="none" linux.dbus="unix:path=/run/user/1000/bus" . 2020.03.14 22:15:54 - Profile path: /home/verylongvmusername_forsafety/.airvpn/default.xml . 2020.03.14 22:15:56 - OpenVPN Driver - Found, /dev/net/tun . 2020.03.14 22:15:56 - OpenVPN - Version: 2.4.4 - OpenSSL 1.1.1 11 Sep 2018, LZO 2.08 (/usr/sbin/openvpn) . 2020.03.14 22:15:56 - SSH - Version: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 (/usr/bin/ssh) . 2020.03.14 22:15:56 - SSL - Version: stunnel 5.44 (/usr/bin/stunnel4) . 2020.03.14 22:15:56 - curl - Version: 7.58.0 (/usr/bin/curl) . 2020.03.14 22:15:56 - Certification Authorities: /usr/share/eddie-ui/cacert.pem . 2020.03.14 22:15:56 - Updating systems & servers data ... I 2020.03.14 22:15:56 - Ready I 2020.03.14 22:15:58 - Session starting. I 2020.03.14 22:15:58 - Checking authorization ... . 2020.03.14 22:17:16 - Cannot retrieve systems & servers data. (curl: (28) Connection timed out after 20000 milliseconds) W 2020.03.14 22:17:18 - Authorization check failed, continue anyway (curl: (28) Connection timed out after 20000 milliseconds) ! 2020.03.14 22:17:18 - Connecting to Rotanev (Canada, Toronto, Ontario) . 2020.03.14 22:17:18 - OpenVPN > OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019 . 2020.03.14 22:17:18 - OpenVPN > library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08 . 2020.03.14 22:17:18 - Connection to OpenVPN Management Interface . 2020.03.14 22:17:18 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100 . 2020.03.14 22:17:18 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2020.03.14 22:17:18 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2020.03.14 22:17:18 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2020.03.14 22:17:18 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2020.03.14 22:17:18 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]104.254.90.189:443 . 2020.03.14 22:17:18 - OpenVPN > Socket Buffers: R=[212992->212992] S=[212992->212992] . 2020.03.14 22:17:18 - OpenVPN > UDP link local: (not bound) . 2020.03.14 22:17:18 - OpenVPN > UDP link remote: [AF_INET]104.254.90.189:443 . 2020.03.14 22:17:18 - OpenVPN > TLS: Initial packet from [AF_INET]104.254.90.189:443, sid=2f7cdf9c aa9c6f95 . 2020.03.14 22:17:18 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2020.03.14 22:17:18 - OpenVPN > VERIFY KU OK . 2020.03.14 22:17:18 - OpenVPN > Validating certificate extended key usage . 2020.03.14 22:17:18 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2020.03.14 22:17:18 - OpenVPN > VERIFY EKU OK . 2020.03.14 22:17:18 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Rotanev, emailAddress=info@airvpn.org . 2020.03.14 22:17:18 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100 . 2020.03.14 22:17:18 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA . 2020.03.14 22:17:18 - OpenVPN > [Rotanev] Peer Connection Initiated with [AF_INET]104.254.90.189:443 . 2020.03.14 22:17:19 - OpenVPN > SENT CONTROL [Rotanev]: 'PUSH_REQUEST' (status=1) . 2020.03.14 22:17:19 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.28.86.1,dhcp-option DNS6 fde6:7a:7d20:1856::1,tun-ipv6,route-gateway 10.28.86.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:1856::103c/64 fde6:7a:7d20:1856::1,ifconfig 10.28.86.62 255.255.255.0,peer-id 4,cipher AES-256-GCM' . 2020.03.14 22:17:19 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2020.03.14 22:17:19 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:1856::1' . 2020.03.14 22:17:19 - OpenVPN > Pushed option removed by filter: 'tun-ipv6' . 2020.03.14 22:17:19 - OpenVPN > Pushed option removed by filter: 'ifconfig-ipv6 fde6:7a:7d20:1856::103c/64 fde6:7a:7d20:1856::1' . 2020.03.14 22:17:19 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2020.03.14 22:17:19 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2020.03.14 22:17:19 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2020.03.14 22:17:19 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2020.03.14 22:17:19 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified . 2020.03.14 22:17:19 - OpenVPN > OPTIONS IMPORT: peer-id set . 2020.03.14 22:17:19 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625 . 2020.03.14 22:17:19 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2020.03.14 22:17:19 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2020.03.14 22:17:19 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2020.03.14 22:17:19 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2020.03.14 22:17:19 - OpenVPN > ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=enp0s3 HWADDR=08:00:27:eb:7d:d6 . 2020.03.14 22:17:20 - OpenVPN > TUN/TAP device tun0 opened . 2020.03.14 22:17:20 - OpenVPN > TUN/TAP TX queue length set to 100 . 2020.03.14 22:17:20 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=0 . 2020.03.14 22:17:20 - OpenVPN > /sbin/ip link set dev tun0 up mtu 1500 . 2020.03.14 22:17:20 - OpenVPN > /sbin/ip addr add dev tun0 10.28.86.62/24 broadcast 10.28.86.255 . 2020.03.14 22:17:25 - OpenVPN > /sbin/ip route add 104.254.90.189/32 via 192.168.0.1 . 2020.03.14 22:17:25 - OpenVPN > /sbin/ip route add 0.0.0.0/1 via 10.28.86.1 . 2020.03.14 22:17:25 - OpenVPN > /sbin/ip route add 128.0.0.0/1 via 10.28.86.1 . 2020.03.14 22:17:25 - /etc/resolv.conf moved to /etc/resolv.conf.eddie as backup . 2020.03.14 22:17:25 - DNS of the system updated to VPN DNS (Rename method: /etc/resolv.conf generated) . 2020.03.14 22:17:25 - Routes, added a new route, 104.254.90.187 for gateway 10.28.86.1 . 2020.03.14 22:17:25 - Unable to compute route for 2606:6080:2001:5:48ec:2d6:cc35:3864: IPv6 VPN gateway not available. . 2020.03.14 22:17:25 - Flushing DNS I 2020.03.14 22:17:26 - Checking route IPv4 I 2020.03.14 22:17:26 - Checking DNS ! 2020.03.14 22:17:27 - Connected. . 2020.03.14 22:17:27 - OpenVPN > Initialization Sequence Completed My rules : *filter # Drop all traffic by default -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP # Allow inbound from already-established connections. May optionally change to "--ctstate RELATED,ESTABLISHED" to include related connections as well. -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Allow loopback interface and ping. -A INPUT -i lo -j ACCEPT -A OUTPUT -o lo -j ACCEPT # Allow DHCP traffic -A OUTPUT -d 255.255.255.255 -j ACCEPT -A INPUT -s 255.255.255.255 -j ACCEPT # Allow LAN traffic -A OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT -A INPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT # Allow traffic between interface -A FORWARD -i enp0s3 -o tun0 -j ACCEPT -A FORWARD -i tun0 -o enp0s3 -j ACCEPT # Allow traffic to VPN in LAN range -A OUTPUT -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT -A INPUT -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT # Allow VPN service port and interface -A OUTPUT -p udp -m udp --dport 443 -j ACCEPT -A OUTPUT -o tun0 -j ACCEPT # FrontEnd servers -A OUTPUT -d 5.196.64.52 -j ACCEPT -A OUTPUT -d 95.211.138.143 -j ACCEPT # Rotanev -A OUTPUT -d 104.254.90.186 -j ACCEPT -A OUTPUT -d 104.254.90.189 -j ACCEPT COMMIT Edited ... by giganerd Apply LOG formatting to logs Share this post Link to post
OpenSourcerer 1435 Posted ... 6 hours ago, pfillionqc said: # Drop all traffic by default -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP Shouldn't this be at the end, or does order not matter? Hide OpenSourcerer's signature Hide all signatures NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT. LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too! Want to contact me directly? All relevant methods are on my About me page. Share this post Link to post
Staff 9973 Posted ... @pfillionqc Hello! Please make sure that UFW is disabled. It is an iptables frontend installed by default in Ubuntu. It creates custom chains and modifies rules, so you don't want it to interfere. Please allow packets to an additional bootstrap server too: -A OUTPUT -d 63.33.78.166 -j ACCEPT Also consider to drop Eddie 2.16.3 and use instead Eddie 2.18.7 beta or Hummingbird 1.0.2 Keep in mind that when you enable "Network Lock" feature your iptables rules will be overwritten by Eddie or Hummingbird and restored when the application exits, but that UFW can still cause troubles.@giganerd Those are filter table INPUT, OUTPUT and FORWARD chains' policies and it's correct that they are set to DROP. Any packet handled by any chain of the filter table that has not caused any jump in any rule is finally subjected to the default policy of the chain that's competent for that packet. Kind regards 2 OpenSourcerer and pfillionqc reacted to this Share this post Link to post
pfillionqc 0 Posted ... (edited) Thank* you for your help. However, it did not solve my problem. I did further testing as I became more comfortable on how iptables works. My problem was that Eddie could not communicate with 63.33.78.166:80 in TCP. Everything is working good now. I included the current version of my file... maybe it can help someone else. My network interface is enp0s3 (not eth0). ipv4 file : *filter # Reminder, DO NOT UNCOMMENT (Need to be done in terminal) # sudo iptables -F # sudo iptables -X # sudo iptables-restore < ./ipv4 # sudo ip6tables -F # sudo ip6tables -X # sudo ip6tables-restore < ./ipv6 # sudo dpkg-reconfigure iptables-persistent # Drop all traffic by default -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP # Allow inbound from already-established connections. May optionally change to "--ctstate RELATED,ESTABLISHED" to include related connections as well. -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Allow loopback interface -A INPUT -i lo -j ACCEPT -A OUTPUT -o lo -j ACCEPT # Allow DHCP traffic -A OUTPUT -d 255.255.255.255 -j ACCEPT -A INPUT -s 255.255.255.255 -j ACCEPT # Allow LAN traffic -A OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT -A INPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT -A OUTPUT -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT -A INPUT -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT # Allow traffic between interface -A FORWARD -i enp0s3 -o tun0 -j ACCEPT -A FORWARD -i tun0 -o enp0s3 -j ACCEPT # Allow VPN interface -A OUTPUT -o tun0 -j ACCEPT # AirVPN Auth server -A OUTPUT -p tcp -d 63.33.78.166 --dport 80 -j ACCEPT # AirVPN Rotanev -A OUTPUT -p udp -d 104.254.90.189 --dport 443 -j ACCEPT -A OUTPUT -p tcp -d 104.254.90.189 --dport 89 -j ACCEPT # AirVPN Port Forwarding -A INPUT -i tun0 -p tcp --dport 12345 -j ACCEPT -A INPUT -i tun0 -p udp --dport 12345 -j ACCEPT # Debug (Uncomment to log in /var/log/syslog) #-N LOGGING #-A INPUT -j LOGGING #-A FORWARD -j LOGGING #-A OUTPUT -j LOGGING #-A LOGGING -m limit --limit 2/min -j LOG --log-prefix "##### DROPPED : " --log-level 4 #-A LOGGING -j DROP COMMIT Edited ... by pfillionqc Fixed outgoing 443 port that could communicate to unsafe destination Share this post Link to post
Staff 9973 Posted ... @pfillionqc Hello! Yes, thank you for your correction, it was a mistake on our side. We are editing our message to not create confusion to thread future readers. We're glad to know that you managed to resolve the problem. Enjoy AirVPN! Kind regards Share this post Link to post