search

jotyGill / openpyn-nordvpn

Easily connect to and switch between, OpenVPN servers hosted by NordVPN on Linux (+patch leakes)
GNU General Public License v3.0
628 stars 114 forks source link

Slow script execution issue #154

Open genox87 opened 6 years ago

genox87 commented 6 years ago

Hello, i've a problem with openpyn, the program it self run without issue but between the "pings" to check witch server it's the faster and the openvpn connection, require more then 40 sec, i'm using pop os, based on ubuntu 18.04.

Also tryed on a clean debian minimal install and i dont have this problem

user@pc:~$ openpyn -f it
Flushing iptables INPUT and OUTPUT chains AND Applying default Rules
According to NordVPN, Least Busy 10 Servers, In IT With 'Load' less than 70 Which Support OPENVPN-UDP are : [['it15', 15], ['it16', 16], ['it17', 19], ['it23', 19], ['it31', 19], ['it35', 19], ['it22', 22], ['it18', 23], ['it20', 24], ['it14', 25]] 

Pinging Server it15 min/avg/max/mdev =  [30, 31, 31, 0] 

Pinging Server it16 min/avg/max/mdev =  [33, 33, 34, 0] 

Pinging Server it17 min/avg/max/mdev =  [30, 31, 31, 0] 

Pinging Server it23 min/avg/max/mdev =  [31, 31, 32, 0] 

Pinging Server it31 min/avg/max/mdev =  [30, 30, 30, 0] 

Pinging Server it35 min/avg/max/mdev =  [31, 32, 32, 0] 

Pinging Server it22 min/avg/max/mdev =  [32, 32, 33, 0] 

Pinging Server it18 min/avg/max/mdev =  [30, 31, 31, 0] 

Pinging Server it20 min/avg/max/mdev =  [32, 32, 32, 0] 

Pinging Server it14 min/avg/max/mdev =  [31, 31, 31, 0] 

Top 10 Servers with best Ping are: ['it31', 'it15', 'it17', 'it23', 'it18', 'it14', 'it35', 'it22', 'it20', 'it16']

~ wait 40 / 50 sec

Out of the Best Available Servers, Chose it31
CONNECTING TO SERVER it31 ON PORT udp

Your OS' linux' has systemd-resolve running  using it to update DNS Resolver Entries
Sat May 26 17:38:14 2018 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2018
Sat May 26 17:38:14 2018 library versions: OpenSSL 1.1.0g  2 Nov 2017, LZO 2.08
Sat May 26 17:38:14 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:7015
Sat May 26 17:38:14 2018 WARNING: --ping should normally be used with --ping-restart or --ping-exit
Sat May 26 17:38:14 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat May 26 17:38:14 2018 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat May 26 17:38:14 2018 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat May 26 17:38:14 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]82.102.21.78:1194
Sat May 26 17:38:14 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat May 26 17:38:14 2018 UDP link local: (not bound)
Sat May 26 17:38:14 2018 UDP link remote: [AF_INET]82.102.21.78:1194
Sat May 26 17:38:15 2018 TLS: Initial packet from [AF_INET]82.102.21.78:1194, sid=1570c20f 0a508847
Sat May 26 17:38:15 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat May 26 17:38:15 2018 VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Sat May 26 17:38:15 2018 VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA2
Sat May 26 17:38:15 2018 VERIFY KU OK
Sat May 26 17:38:15 2018 Validating certificate extended key usage
Sat May 26 17:38:15 2018 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat May 26 17:38:15 2018 VERIFY EKU OK
Sat May 26 17:38:15 2018 VERIFY OK: depth=0, CN=it31.nordvpn.com
Sat May 26 17:38:15 2018 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sat May 26 17:38:15 2018 [it31.nordvpn.com] Peer Connection Initiated with [AF_INET]82.102.21.78:1194
Sat May 26 17:38:16 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:7015
Sat May 26 17:38:16 2018 SENT CONTROL [it31.nordvpn.com]: 'PUSH_REQUEST' (status=1)
Sat May 26 17:38:16 2018 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,sndbuf 524288,rcvbuf 524288,dhcp-option DNS 103.86.96.100,dhcp-option DNS 103.86.99.100,route-gateway 10.8.8.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.8.8.110 255.255.255.0,peer-id 2,cipher AES-256-GCM'
Sat May 26 17:38:16 2018 OPTIONS IMPORT: timers and/or timeouts modified
Sat May 26 17:38:16 2018 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sat May 26 17:38:16 2018 Socket Buffers: R=[212992->425984] S=[212992->425984]
Sat May 26 17:38:16 2018 OPTIONS IMPORT: --ifconfig/up options modified
Sat May 26 17:38:16 2018 OPTIONS IMPORT: route options modified
Sat May 26 17:38:16 2018 OPTIONS IMPORT: route-related options modified
Sat May 26 17:38:16 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat May 26 17:38:16 2018 OPTIONS IMPORT: peer-id set
Sat May 26 17:38:16 2018 OPTIONS IMPORT: adjusting link_mtu to 1657
Sat May 26 17:38:16 2018 OPTIONS IMPORT: data channel crypto options modified
Sat May 26 17:38:16 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Sat May 26 17:38:16 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat May 26 17:38:16 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat May 26 17:38:16 2018 ROUTE_GATEWAY 192.168.120.1/255.255.255.0 IFACE=enp9s0 HWADDR=10:bf:48:82:cc:1e
Sat May 26 17:38:16 2018 TUN/TAP device tun0 opened
Sat May 26 17:38:16 2018 TUN/TAP TX queue length set to 100
Sat May 26 17:38:16 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat May 26 17:38:16 2018 /sbin/ip link set dev tun0 up mtu 1500
Sat May 26 17:38:16 2018 /sbin/ip addr add dev tun0 10.8.8.110/24 broadcast 10.8.8.255
Sat May 26 17:38:16 2018 /usr/local/lib/python3.6/dist-packages/openpyn/scripts/update-systemd-resolved.sh tun0 1500 1585 10.8.8.110 255.255.255.0 init
<14>May 26 17:38:16 update-systemd-resolved.sh: Link 'tun0' coming up
<14>May 26 17:38:16 update-systemd-resolved.sh: Adding IPv4 DNS Server 103.86.96.100
<14>May 26 17:38:16 update-systemd-resolved.sh: Adding IPv4 DNS Server 103.86.99.100
<14>May 26 17:38:16 update-systemd-resolved.sh: SetLinkDNS(3 2 2 4 103 86 96 100 2 4 103 86 99 100)
Sat May 26 17:38:16 2018 /sbin/ip route add 82.102.21.78/32 via 192.168.120.1
Sat May 26 17:38:16 2018 /sbin/ip route add 0.0.0.0/1 via 10.8.8.1
Sat May 26 17:38:16 2018 /sbin/ip route add 128.0.0.0/1 via 10.8.8.1
Sat May 26 17:38:16 2018 Initialization Sequence Completed

There's a way to enable a debug mode or something to understand what the program does during that time ?

python3 -V
Python 3.6.5

openpyn -v
openpyn 2.6.0

Thanks

yuriw commented 6 years ago

how do you have your DNS set up ? how many nameservers ?

I recently solved similar issues using these steps:

sudo apt install openresolv

Create a script

sudo vi /usr/share/openvpn/update-resolv-conf.sh

as in https://github.com/masterkorp/openvpn-update-resolv-conf/blob/master/update-resolv-conf.sh (see below)

In OpenVPN configuration file that you use to connect to NordVPN server (e.g. de167.nordvpn.com.udp.ovpn) add these lines (need to apply to openpyn script I guess):

script-security 2 up /usr/share/openvpn/update-resolv-conf.sh down /usr/share/openvpn/update-resolv-conf.sh

check resolv.conf when connect and disconnected

Hope it helps.

genox87 commented 6 years ago

Well, my dns are handled by dhcp server ( router ) ( 192.168.120.1 ) on the router i've set 1.1.1.1 and 1.0.0.1, so basically every cached request are answered from router, while uncached forward to cloudflare dns.

I'll check your suggestion to use openresolv as soon i get home and report back

Thanks

jotyGill commented 6 years ago

Hi, Obvious thing would be if your "ping" didn't support -i or -n options. In that case 1 second is the minimum wait between between every ping request. but that should print a warning.

try pinging. with ping -n -i .2 -c 10 it21.nordvpn.com etc

then try pinging a new server using it's ip. Check if it is the name resolution or pings that are taking long. you can grab the ips from the vpn config files in "openpyn/files/" folder

BTW, is it same when you don't use option "-f" ?

debug mode is actually being implemented at the moment.

genox87 commented 6 years ago

Hello, @yuriw aint got the time to try your solution yet, hope to find some time later.

@jotyGill according to "ping" my distro supports both -n and -i :

Usage: ping [-aAbBdDfhLnOqrRUvV64] [-c count] [-i interval] [-I interface]
            [-m mark] [-M pmtudisc_option] [-l preload] [-p pattern] [-Q tos]
            [-s packetsize] [-S sndbuf] [-t ttl] [-T timestamp_option]
            [-w deadline] [-W timeout] [hop1 ...] destination

user@pc:~$ time ping -n -i .2 -c 10 it11.nordvpn.com
PING it11.nordvpn.com (185.94.193.181) 56(84) bytes of data.
64 bytes from 185.94.193.181: icmp_seq=1 ttl=56 time=31.0 ms
64 bytes from 185.94.193.181: icmp_seq=2 ttl=56 time=30.5 ms
64 bytes from 185.94.193.181: icmp_seq=3 ttl=56 time=30.7 ms
64 bytes from 185.94.193.181: icmp_seq=4 ttl=56 time=30.6 ms
64 bytes from 185.94.193.181: icmp_seq=5 ttl=56 time=37.3 ms
64 bytes from 185.94.193.181: icmp_seq=6 ttl=56 time=30.5 ms
64 bytes from 185.94.193.181: icmp_seq=7 ttl=56 time=30.0 ms
64 bytes from 185.94.193.181: icmp_seq=8 ttl=56 time=30.6 ms
64 bytes from 185.94.193.181: icmp_seq=9 ttl=56 time=31.1 ms
64 bytes from 185.94.193.181: icmp_seq=10 ttl=56 time=30.5 ms

--- it11.nordvpn.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1806ms
rtt min/avg/max/mdev = 30.054/31.334/37.326/2.030 ms

real    0m1,841s
user    0m0,000s
sys 0m0,004s

also, test with only the IP of a random uncached nordvpn server :

user@pc:~$ time ping -n -i .2 -c 10 103.86.96.100
PING 103.86.96.100 (103.86.96.100) 56(84) bytes of data.
64 bytes from 103.86.96.100: icmp_seq=1 ttl=50 time=411 ms
64 bytes from 103.86.96.100: icmp_seq=2 ttl=50 time=410 ms
64 bytes from 103.86.96.100: icmp_seq=3 ttl=50 time=410 ms
64 bytes from 103.86.96.100: icmp_seq=4 ttl=50 time=411 ms
64 bytes from 103.86.96.100: icmp_seq=5 ttl=50 time=411 ms
64 bytes from 103.86.96.100: icmp_seq=6 ttl=50 time=411 ms
64 bytes from 103.86.96.100: icmp_seq=7 ttl=50 time=411 ms
64 bytes from 103.86.96.100: icmp_seq=8 ttl=50 time=410 ms
64 bytes from 103.86.96.100: icmp_seq=9 ttl=50 time=410 ms
64 bytes from 103.86.96.100: icmp_seq=10 ttl=50 time=410 ms

--- 103.86.96.100 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1814ms
rtt min/avg/max/mdev = 410.692/411.130/411.885/0.659 ms, pipe 3

real    0m2,228s
user    0m0,000s
sys 0m0,004s

As you can see, cached dns or direct ip ping, takes at most 2sec

BTW, is it same when you don't use option "-f" ?

This is a try with cached sudo credential, so basically wont ask to input the user password to perform the openvpn connection, between the command and control +c to stop the vpn it took less then 14 sec.. so the problem seems to be the -f switch :\

user@pc:~$ time openpyn uk
According to NordVPN, Least Busy 10 Servers, In UK With 'Load' less than 70 Which Support OPENVPN-UDP are : [['uk269', 4], ['uk391', 4], ['uk418', 5], ['uk460', 5], ['uk283', 6], ['uk407', 6], ['uk599', 6], ['uk603', 6], ['uk650', 6], ['uk123', 7]] 

Pinging Server uk269 min/avg/max/mdev =  [51, 51, 51, 0] 

Pinging Server uk391 min/avg/max/mdev =  [59, 59, 59, 0] 

Pinging Server uk418 min/avg/max/mdev =  [63, 63, 64, 0] 

Pinging Server uk460 min/avg/max/mdev =  [51, 51, 51, 0] 

Pinging Server uk283 min/avg/max/mdev =  [56, 56, 56, 0] 

Pinging Server uk407 min/avg/max/mdev =  [51, 51, 51, 0] 

Pinging Server uk599 min/avg/max/mdev =  [61, 61, 62, 0] 

Pinging Server uk603 min/avg/max/mdev =  [62, 62, 63, 0] 

Pinging Server uk650 min/avg/max/mdev =  [58, 59, 59, 0] 

Pinging Server uk123 min/avg/max/mdev =  [54, 54, 54, 0] 

Top 10 Servers with best Ping are: ['uk269', 'uk460', 'uk407', 'uk123', 'uk283', 'uk391', 'uk650', 'uk599', 'uk603', 'uk418']

Out of the Best Available Servers, Chose uk269
CONNECTING TO SERVER uk269 ON PORT udp

Your OS' linux' has systemd-resolve running  using it to update DNS Resolver Entries
Sun May 27 11:39:24 2018 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2018
Sun May 27 11:39:24 2018 library versions: OpenSSL 1.1.0g  2 Nov 2017, LZO 2.08
Sun May 27 11:39:24 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:7015
Sun May 27 11:39:24 2018 WARNING: --ping should normally be used with --ping-restart or --ping-exit
Sun May 27 11:39:24 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun May 27 11:39:24 2018 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sun May 27 11:39:24 2018 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sun May 27 11:39:24 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]81.92.203.48:1194
Sun May 27 11:39:24 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun May 27 11:39:24 2018 UDP link local: (not bound)
Sun May 27 11:39:24 2018 UDP link remote: [AF_INET]81.92.203.48:1194
Sun May 27 11:39:24 2018 TLS: Initial packet from [AF_INET]81.92.203.48:1194, sid=6da3c393 cbeef43e
Sun May 27 11:39:24 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun May 27 11:39:24 2018 VERIFY OK: depth=1, C=PA, ST=PA, L=Panama, O=NordVPN, OU=NordVPN, CN=uk269.nordvpn.com, name=NordVPN, emailAddress=cert@nordvpn.com
Sun May 27 11:39:24 2018 VERIFY KU OK
Sun May 27 11:39:24 2018 Validating certificate extended key usage
Sun May 27 11:39:24 2018 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun May 27 11:39:24 2018 VERIFY EKU OK
Sun May 27 11:39:24 2018 VERIFY OK: depth=0, C=PA, ST=PA, L=Panama, O=NordVPN, OU=NordVPN, CN=uk269.nordvpn.com, name=NordVPN, emailAddress=cert@nordvpn.com
Sun May 27 11:39:24 2018 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sun May 27 11:39:24 2018 [uk269.nordvpn.com] Peer Connection Initiated with [AF_INET]81.92.203.48:1194
Sun May 27 11:39:25 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:7015
Sun May 27 11:39:25 2018 SENT CONTROL [uk269.nordvpn.com]: 'PUSH_REQUEST' (status=1)
Sun May 27 11:39:25 2018 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,sndbuf 524288,rcvbuf 524288,dhcp-option DNS 103.86.96.100,dhcp-option DNS 103.86.99.100,route-gateway 10.8.8.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.8.8.197 255.255.255.0,peer-id 7,cipher AES-256-GCM'
Sun May 27 11:39:25 2018 OPTIONS IMPORT: timers and/or timeouts modified
Sun May 27 11:39:25 2018 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sun May 27 11:39:25 2018 Socket Buffers: R=[212992->425984] S=[212992->425984]
Sun May 27 11:39:25 2018 OPTIONS IMPORT: --ifconfig/up options modified
Sun May 27 11:39:25 2018 OPTIONS IMPORT: route options modified
Sun May 27 11:39:25 2018 OPTIONS IMPORT: route-related options modified
Sun May 27 11:39:25 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun May 27 11:39:25 2018 OPTIONS IMPORT: peer-id set
Sun May 27 11:39:25 2018 OPTIONS IMPORT: adjusting link_mtu to 1657
Sun May 27 11:39:25 2018 OPTIONS IMPORT: data channel crypto options modified
Sun May 27 11:39:25 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Sun May 27 11:39:25 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun May 27 11:39:25 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun May 27 11:39:25 2018 ROUTE_GATEWAY 192.168.120.1/255.255.255.0 IFACE=enp9s0 HWADDR=10:bf:48:82:cc:1e
Sun May 27 11:39:25 2018 TUN/TAP device tun0 opened
Sun May 27 11:39:25 2018 TUN/TAP TX queue length set to 100
Sun May 27 11:39:25 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun May 27 11:39:25 2018 /sbin/ip link set dev tun0 up mtu 1500
Sun May 27 11:39:25 2018 /sbin/ip addr add dev tun0 10.8.8.197/24 broadcast 10.8.8.255
Sun May 27 11:39:25 2018 /usr/local/lib/python3.6/dist-packages/openpyn/scripts/update-systemd-resolved.sh tun0 1500 1585 10.8.8.197 255.255.255.0 init
<14>May 27 11:39:25 update-systemd-resolved.sh: Link 'tun0' coming up
<14>May 27 11:39:25 update-systemd-resolved.sh: Adding IPv4 DNS Server 103.86.96.100
<14>May 27 11:39:25 update-systemd-resolved.sh: Adding IPv4 DNS Server 103.86.99.100
<14>May 27 11:39:25 update-systemd-resolved.sh: SetLinkDNS(5 2 2 4 103 86 96 100 2 4 103 86 99 100)
Sun May 27 11:39:25 2018 /sbin/ip route add 81.92.203.48/32 via 192.168.120.1
Sun May 27 11:39:25 2018 /sbin/ip route add 0.0.0.0/1 via 10.8.8.1
Sun May 27 11:39:25 2018 /sbin/ip route add 128.0.0.0/1 via 10.8.8.1
Sun May 27 11:39:25 2018 Initialization Sequence Completed
^CSun May 27 11:39:28 2018 event_wait : Interrupted system call (code=4)
Sun May 27 11:39:28 2018 SIGTERM received, sending exit notification to peer

Shutting down safely, please wait until process exits

Sun May 27 11:39:28 2018 MANAGEMENT: Client disconnected
Sun May 27 11:39:31 2018 /sbin/ip route del 81.92.203.48/32
Sun May 27 11:39:31 2018 /sbin/ip route del 0.0.0.0/1
Sun May 27 11:39:31 2018 /sbin/ip route del 128.0.0.0/1
Sun May 27 11:39:31 2018 /usr/local/lib/python3.6/dist-packages/openpyn/scripts/update-systemd-resolved.sh tun0 1500 1585 10.8.8.197 255.255.255.0 init
<14>May 27 11:39:31 update-systemd-resolved.sh: Link 'tun0' going down
Sun May 27 11:39:31 2018 Closing TUN/TAP interface
Sun May 27 11:39:31 2018 /sbin/ip addr del dev tun0 10.8.8.197/24
Sun May 27 11:39:31 2018 SIGTERM[soft,exit-with-notification] received, process exiting

real    0m13,356s
user    0m0,489s
sys 0m0,287s

So the problem seems to be with the -f Flag, also when i run the -x to flush the iptables rules (already done ctrl+c, so openvpn its not running ) takes a while....

user@pc:~$ time openpyn -x
Flushing iptables INPUT and OUTPUT chains AND Applying default Rules
Terminato

real    0m50,720s
user    0m0,383s
sys 0m0,168s

So, what happend here between:

Top 10 Servers with best Ping are: ['fr131', 'fr36', 'fr130', 'fr117', 'fr67', 'fr109', 'fr85', 'fr108', 'fr27', 'fr171'] and:

Out of the Best Available Servers, Chose fr131
CONNECTING TO SERVER fr131 ON PORT udp

There are some kind of timeout ? maybe the os don't reply in time, and wait for the timeout of the command ?

Thanks, Regards.

jotyGill commented 6 years ago

Hi, Ok in your case, it looks like the OS is taking a long time to flush and apply the new IPTables rules. That's what happens at the position where it's taking time. That shouldn't have anything to do with openpyn's internal logic itself. Same when using "openpyn -x". Upgrade to the latest version. you can find the logs at /var/log/openpyn/ (although they got nothing more than the output with timestamps there). You can try running the IPtables commands manually to check it. openpyn -x runs the following

    subprocess.call(["sudo", "iptables", "-F", "OUTPUT"])
    # allow all outgoing traffic
    subprocess.call("sudo iptables -P OUTPUT ACCEPT".split())

    subprocess.call(["sudo", "iptables", "-F", "INPUT"])
    subprocess.call(["sudo", "iptables", "-A", "INPUT", "-i", "lo", "-j", "ACCEPT"])
    subprocess.call(["sudo", "iptables", "-A", "OUTPUT", "-o", "lo", "-j", "ACCEPT"])
    subprocess.call(
        "sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT".split())
    # allow ICMP traffic
    subprocess.call("sudo iptables -A INPUT -p icmp --icmp-type any -j ACCEPT".split())
    # best practice, stops spoofing
    subprocess.call("sudo iptables -A INPUT -s 127.0.0.0/8 -j DROP".split())
    # drop anything else incoming
    subprocess.call("sudo iptables -P INPUT DROP".split())