Jump to content
Not connected, Your IP:

ANSWERED Eddie slow to apply iptables rules

Recommended Posts

I'm running Eddie 2.16.3 installed from AUR on Manjaro with kernel 4.18.5 and I'm finding that network lock takes a long time to apply all the rules required. From the logs :


2018.09.05 11:46:39 - Shell(15) of '/usr/sbin/iptables', 1 args: '-P INPUT ACCEPT';
2018.09.05 11:46:40 - Shell(15) done in 297 ms, exit: 0
2018.09.05 11:46:40 - Shell(16) of '/usr/sbin/iptables', 1 args: '-P FORWARD ACCEPT';
2018.09.05 11:46:40 - Shell(16) done in 270 ms, exit: 0
2018.09.05 11:52:32 - Shell(1336) of '/usr/sbin/ip6tables', 1 args: '-I OUTPUT 1 -d 2a0d:5600:2:5:5200:5517:2b3b:f9b6 -j ACCEPT';
2018.09.05 11:52:32 - Shell(1336) done in 263 ms, exit: 0
2018.09.05 11:52:32 - Shell(1337) of '/usr/sbin/ip6tables', 1 args: '-I OUTPUT 1 -d 2a0d:5600:2:5:cf41:c8d8:2e78:17b2 -j ACCEPT';
2018.09.05 11:52:32 - Shell(1337) done in 260 ms, exit: 0

As you can see this takes a long time (around 6 minutes) with iptables version 1.6.2. At the moment I've got a workaround by just backing up / restoring the iptables rules using

iptables-save > iptables_rules_AirVPN.txt

iptables-restore < iptables_rules_AirVPN.txt 

This change is immediate but I understand that this isn't great as things will change. Anyone else encountered similar?

Share this post

Link to post

I do not have ufw installed.
iptables rule entered form terminal is fast.
It looks like every shell command from Eddie is slow, even these:

. 2018.09.11 21:05:33 - Shell(9) of '/usr/sbin/openvpn', 1 args: '--version';
. 2018.09.11 21:05:33 - Shell(9) done in 460 ms, exit: 1, out: 'OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
. 2018.09.11 21:05:33 -     library versions: OpenSSL 1.1.0i  14 Aug 2018, LZO 2.10
. 2018.09.11 21:05:33 -     Originally developed by James Yonan
. 2018.09.11 21:05:33 -     Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net>
. 2018.09.11 21:05:33 -     Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no'
. 2018.09.11 21:05:33 - Shell(10) of '/usr/sbin/ssh', 1 args: '-V';
. 2018.09.11 21:05:34 - Shell(10) done in 406 ms, exit: 0, err: 'OpenSSH_7.8p1, OpenSSL 1.1.0i  14 Aug 2018'
. 2018.09.11 21:05:34 - Shell(11) of '/usr/sbin/stunnel', 1 args: '-version';
. 2018.09.11 21:05:34 - Shell(11) done in 386 ms, exit: 0, err: 'stunnel 5.48 on x86_64-pc-linux-gnu platform

Share this post

Link to post

If I run Eddie from the command line instead of using Eddie-GUI I get the same issue: no connection possible with network lock enabled. Takes forever and nothing happens. Only difference is that I can stop the command line version, Eddie-GUI will just crash an a reboot is needed to get it running again.

Share this post

Link to post



If you enter an iptables rule from a command line interface as root, is the command faster or equally slow?


Kind regards


Sorry for the slow reply.


2018.09.18 20:22:52 - Shell(54) of '/usr/sbin/iptables', 1 args: '-A OUTPUT -s -d -j ACCEPT';
2018.09.18 20:22:52 - Shell(54) done in 403 ms, exit: 0

sudo perf stat iptables -A OUTPUT -s -d -j ACCEPT

0.003262772 seconds time elapsed

So when I apply the rule it only takes around 3 ms instead of around 400 ms. I'm not running UFW.


In Eddie, go to Preferences > Networking and set 'Layer IPv6' to 'Block'.


Save and restart Eddie.


This has no effect on the time it takes to apply the rules for me.


If I run Eddie from the command line instead of using Eddie-GUI I get the same issue: no connection possible with network lock enabled. Takes forever and nothing happens. Only difference is that I can stop the command line version, Eddie-GUI will just crash an a reboot is needed to get it running again.


In the end it does finish applying the rules (you can see it in the Logs tab of Eddie if you enable logging under settings). If you let it finish and then use the iptables-save / iptables-restore commands I showed in my first post you can use this as a temporary workaround and still have a (kind-of) working network lock.

Share this post

Link to post

This problem still persists (for me) in Manjaro, even with Eddie version 2.17.2
Is the network lock faster for the other users who reported about this issue, now? 
(I wonder is there something in the settings I have missed?)


*Also reading the the selected best answer:

Eddie 2.17beta (2.17.1) sure made life easier, now network lock executes only one shell command on activation, and it is tolerable now.
--This is not happening on Eddie 2.17.2 running on Manjaro XFCE, Eddie is still issuing over 1000 shell commands... that take about 10 minutes on this low-end linux-box to complete.

Share this post

Link to post

I can also confirm this problem with a clean (and updated) Manjaro KDE installation.


With the Network lock enabled at start-up, Eddie executes a large number (at least 1000) of iptable commands, each taking over 300ms.


Whilst it is applying these commands, I cannot connect to a server, I cannot de-activate the network lock, and I cannot close eddie.


Basically, eddie becomes unresponsive and unusable, and I have to reboot the system


I am using 2.17.2 (but have also tried the latest stable).


Thanks for any help/advice.


(By the way, all is well on Debian Stable and Mint 19.1).

Share this post

Link to post

This started happening few months ago on my Mint 19.1 running kernel 4.15.*
I thought it was triggered by one of the kernel updates, but could not resolve it.
Running Eddie 2.16.3, I updated to 2.17.2, but it was the same behavior and could not get it to apply network lock via new feature (build iptables-save format and apply directly), it just worked the same as 2.16.3.
So I downgraded back to 2.16.3 and when playing around with it, I disconnected computer from network (WiFi) which I normally never do.
I noticed that in this state, the network lock would be applied in under 10 seconds, compared to 180 seconds when computer is connected to WiFi.

Share this post

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Security Check
    Play CAPTCHA Audio
    Refresh Image

  • Create New...