You are not logged in.
Hello,
During my recent installation of Arch, I followed instructions for setting up a stateful firewall using iptables. Things appeared to be working fine, I could successfully ping websites. I also installed ExpressVPN, which I had used for a long time under my previous Manjaro system without any issues.
Overall, network reliability on my new Arch system has been quite poor. I get frequent bouts of losing connection altogether (unable to load any websites, ping attempt returns a "Temporary failure in name resolution" error), even when I've using an Ethernet connection. Right now I'm using a WiFi connection, and while I do have access to the internet, the KDE Network Manager is consistently showing the "Limited connectivity" exclamation mark.
While the internet reliability where I live is rather unpredictable at the best of times, it's never been this bad. I am beginning to wonder whether I have made some mistake in the firewall setup that is causing these network issues. I briefly considered ditching my current configuration, and using nftables instead, which according to the wiki:
nftables comes with a simple and secure firewall configuration stored in the /etc/nftables.conf file.
However, I haven't tried that yet, partly because I'm not too sure how to properly perform that migration, namely how to ensure the old iptables rules are removed fully so as not to interfere with the new nftables default firewall config.
I eventually decided it would be best to post here first before trying anything else on my own, as my knowledge of networking and firewalls is not very advanced, and I could definitely benefit from some expert advice. Would anyone be willing to give me some tips on what diagnostic measures I can run the next time I have a dropout to try and figure out what's causing these problems?
I have attached my current iptables rules below, in case there is anything glaringly obviously wrong in there that someone can notice.
Thank you in advance for any assistance you can provide.
iptables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1021K 1138M ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
432 42563 ACCEPT 0 -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 41 -- * * 0.0.0.0/0 0.0.0.0/0
258 14395 DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
884 128K ACCEPT 1 -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 ctstate NEW
90 3816 IN_SSH 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ctstate NEW
203K 156M UDP 17 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW
2184 100K TCP 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 ctstate NEW
42 3222 REJECT 6 -- * * 0.0.0.0/0 0.0.0.0/0 recent: SET name: TCP-PORTSCAN side: source mask: 255.255.255.255 reject-with tcp-reset
2925 391K REJECT 17 -- * * 0.0.0.0/0 0.0.0.0/0 recent: SET name: UDP-PORTSCAN side: source mask: 255.255.255.255 reject-with icmp-port-unreachable
663 31224 REJECT 0 -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 540 packets, 33147 bytes)
pkts bytes target prot opt in out source destination
60828 10M xvpn 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain IN_SSH (1 references)
pkts bytes target prot opt in out source destination
2 88 LOG_AND_DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0 recent: CHECK seconds: 10 hit_count: 3 TTL-Match name: sshbf side: source mask: 255.255.255.255
9 364 LOG_AND_DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0 recent: CHECK seconds: 1800 hit_count: 4 TTL-Match name: sshbf side: source mask: 255.255.255.255
79 3364 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 recent: SET name: sshbf side: source mask: 255.255.255.255
Chain LOG_AND_DROP (2 references)
pkts bytes target prot opt in out source destination
11 452 LOG 0 -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix "iptables deny: "
11 452 DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain TCP (1 references)
pkts bytes target prot opt in out source destination
2143 98400 REJECT 6 -- * * 0.0.0.0/0 0.0.0.0/0 recent: UPDATE seconds: 60 name: TCP-PORTSCAN side: source mask: 255.255.255.255 reject-with tcp-reset
17 924 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
Chain UDP (1 references)
pkts bytes target prot opt in out source destination
200K 156M REJECT 17 -- * * 0.0.0.0/0 0.0.0.0/0 recent: UPDATE seconds: 60 name: UDP-PORTSCAN side: source mask: 255.255.255.255 reject-with icmp-port-unreachable
0 0 ACCEPT 17 -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
Chain xvpn (1 references)
pkts bytes target prot opt in out source destination
60828 10M xvpn_dns 0 -- * * 0.0.0.0/0 0.0.0.0/0
60314 10M xvpn_ks 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain xvpn_dns (1 references)
pkts bytes target prot opt in out source destination
60828 10M xvpn_dns_iface_exceptions 0 -- * * 0.0.0.0/0 0.0.0.0/0
60828 10M xvpn_dns_ip_exceptions 0 -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP 6 -- * !lo 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
112 7340 DROP 17 -- * !lo 0.0.0.0/0 0.0.0.0/0 udp dpt:53
Chain xvpn_dns_iface_exceptions (1 references)
pkts bytes target prot opt in out source destination
Chain xvpn_dns_ip_exceptions (1 references)
pkts bytes target prot opt in out source destination
402 27021 ACCEPT 17 -- * * 0.0.0.0/0 100.64.100.1 udp dpt:53
Chain xvpn_ks (1 references)
pkts bytes target prot opt in out source destination
60314 10M xvpn_ks_iface_exceptions 0 -- * * 0.0.0.0/0 0.0.0.0/0
31173 6537K xvpn_ks_ip_exceptions 0 -- * * 0.0.0.0/0 0.0.0.0/0
1 316 ACCEPT 17 -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:67:68
74 5028 DROP 0 -- * !lo 0.0.0.0/0 0.0.0.0/0
Chain xvpn_ks_iface_exceptions (1 references)
pkts bytes target prot opt in out source destination
29141 3862K ACCEPT 0 -- * tun0 0.0.0.0/0 0.0.0.0/0
Chain xvpn_ks_ip_exceptions (1 references)
pkts bytes target prot opt in out source destination
376 40430 ACCEPT 0 -- * * 0.0.0.0/0 10.0.0.0/8
0 0 ACCEPT 0 -- * * 0.0.0.0/0 172.16.0.0/12
0 0 ACCEPT 0 -- * * 0.0.0.0/0 192.168.0.0/16
0 0 ACCEPT 0 -- * * 0.0.0.0/0 169.254.0.0/16
0 0 ACCEPT 0 -- * * 0.0.0.0/0 224.0.0.0/24
30163 6455K ACCEPT 0 -- * * 0.0.0.0/0 181.214.175.202 ip6tables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 0 -- * * ::/0 ::/0 ctstate RELATED,ESTABLISHED
21 1596 ACCEPT 0 -- lo * ::/0 ::/0
0 0 ACCEPT 41 -- * * ::/0 ::/0
0 0 DROP 0 -- * * ::/0 ::/0 ctstate INVALID
0 0 ACCEPT 58 -- * * fe80::/10 ::/0
0 0 ACCEPT 17 -- * * ::/0 ::/0 udp spt:547 dpt:546
0 0 IN_SSH 6 -- * * ::/0 ::/0 tcp dpt:22 ctstate NEW
142 24103 UDP 17 -- * * ::/0 ::/0 ctstate NEW
0 0 TCP 6 -- * * ::/0 ::/0 tcp flags:0x17/0x02 ctstate NEW
0 0 ACCEPT 58 -- * * ::/0 ::/0 ipv6-icmptype 128 ctstate NEW
0 0 REJECT 6 -- * * ::/0 ::/0 recent: SET name: TCP-PORTSCAN side: source mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff reject-with tcp-reset
5 447 REJECT 17 -- * * ::/0 ::/0 recent: SET name: UDP-PORTSCAN side: source mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff reject-with icmp6-adm-prohibited
0 0 REJECT 0 -- * * ::/0 ::/0 reject-with icmp6-adm-prohibited
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1 116 xvpn 0 -- * * ::/0 ::/0
Chain IN_SSH (1 references)
pkts bytes target prot opt in out source destination
0 0 LOG_AND_DROP 0 -- * * ::/0 ::/0 recent: CHECK seconds: 10 hit_count: 3 TTL-Match name: sshbf side: source mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
0 0 LOG_AND_DROP 0 -- * * ::/0 ::/0 recent: CHECK seconds: 1800 hit_count: 4 TTL-Match name: sshbf side: source mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
0 0 ACCEPT 0 -- * * ::/0 ::/0 recent: SET name: sshbf side: source mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
Chain LOG_AND_DROP (2 references)
pkts bytes target prot opt in out source destination
0 0 LOG 0 -- * * ::/0 ::/0 LOG flags 0 level 7 prefix "ip6tables deny: "
0 0 DROP 0 -- * * ::/0 ::/0
Chain TCP (1 references)
pkts bytes target prot opt in out source destination
0 0 REJECT 6 -- * * ::/0 ::/0 recent: UPDATE seconds: 60 name: TCP-PORTSCAN side: source mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff reject-with tcp-reset
0 0 ACCEPT 6 -- * * ::/0 ::/0 tcp dpt:80
0 0 ACCEPT 6 -- * * ::/0 ::/0 tcp dpt:443
0 0 ACCEPT 6 -- * * ::/0 ::/0 tcp dpt:22
0 0 ACCEPT 6 -- * * ::/0 ::/0 tcp dpt:53
Chain UDP (1 references)
pkts bytes target prot opt in out source destination
137 23656 REJECT 17 -- * * ::/0 ::/0 recent: UPDATE seconds: 60 name: UDP-PORTSCAN side: source mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff reject-with icmp6-adm-prohibited
0 0 ACCEPT 17 -- * * ::/0 ::/0 udp dpt:53
Chain xvpn (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP 0 -- * !lo ::/0 ::/0 Last edited by fractal_sounds (2023-07-30 07:59:34)
Offline
Overall, network reliability on my new Arch system has been quite poor. I get frequent bouts of losing connection altogether
Please post the output of
lspci -k
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -fDid you try w/o FW and VPN?
Offline
Thank you very much for the response seth. The outputs you requested are attached below. I slightly increased the padding in the second command, because one of the service names was too long and was messing up your nice formatting! ![]()
Did you try w/o FW and VPN?
I configured the firewall quite early on in the install process, and I haven't tried disabling it as yet. I'm not 100% sure, but I don't think I had many issues just with the firewall; there were probably a few occasions, but I suspect that was just my internet connection being sketchy.
The issues seem to have started (or at the very least, gotten significantly more frequent) after installing ExpressVPN. Whether this is because of something specifically related to ExpressVPN, or a combination of the VPN and firewall configs not playing nicely together, or some other issue, I'm not sure. In case it's useful, I have also attached the preferences and diagnostic information available through the ExpressVPN client.
I haven't been able to find a consistent set of circumstances which always results in success/failure of the network connection.
Also, one (potentially dumb) question... Is there any diagnostic information that I should obtain specifically when the internet connection drops entirely, that would be useful in troubleshooting? Because right now as I type this, and have gotten the information you asked for, I have normal connection (well, it says "limited connectivity", but I can still access the internet).
Some general things I've noticed throughout this period, in case it is helpful:
Sometimes, simply disconnecting and reconnecting to the VPN (the same server, or sometimes a different server) would bring back connectivity.
Sometimes, there seems to be an issue specifically with the Ethernet device. Earlier today, I had both Ethernet and WiFi enabled, and VPN enabled and connected. There was no internet connection. As soon as I disabled the Ethernet device via
sudo ip link set "$eth_dev" downwith no change made to the VPN, internet connection resumed. But again, this seems to be intermittent; as I'm typing this, I have re-enabled the Ethernet, VPN still enabled and connected, and I have usable internet connectivity.
While the above could have been a coincidence, similar things have occurred a number of times. It's almost as if the network configuration hits a bad state after some period of use, and making some change (either to the VPN, or switching between Ethernet and WiFi) is enough to reset things to a good state, and the cycle starts again. I don't know if this makes any sense or is possible, but it's what seems to be happening. For what it's worth, I did find this topic on the forums that seems to describe a similar problem of things being fine for a while, then hitting a roadblock.
Even when I do have internet connection, the Limited Connectivity warning seems to be ever-present on the KDE Plasma Networks icon in the taskbar. I'm not sure whether this is just due to poor connectivity in my area, or another sign that something is amiss with my configurations. I don't believe it used to be present this frequently on my previous Manjaro system.
While I have said that the connection where I live can be unpredictable, I'm almost certain there's something not quite right with the way my Arch system is interacting with either the VPN client or the firewall or both. For instance, when I've had connection issues on Arch (by which I mean zero connection, no internet, ping failure), other devices (MacBook Pro, tablet) that also use ExpressVPN continue to have normal internet connectivity.
lspci -k
00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers (rev 07)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. 8th Gen Core Processor Host Bridge/DRAM Registers
Kernel driver in use: skl_uncore
00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) (rev 07)
Subsystem: Razer USA Ltd. 6th-10th Gen Core Processor PCIe Controller (x16)
Kernel driver in use: pcieport
00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630]
DeviceName: Onboard - Video
Subsystem: Razer USA Ltd. CoffeeLake-H GT2 [UHD Graphics 630]
Kernel driver in use: i915
Kernel modules: i915
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 07)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device_pci_legacy
00:12.0 Signal processing controller: Intel Corporation Cannon Lake PCH Thermal Controller (rev 10)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. Cannon Lake PCH Thermal Controller
Kernel driver in use: intel_pch_thermal
Kernel modules: intel_pch_thermal
00:14.0 USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller (rev 10)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. Cannon Lake PCH USB 3.1 xHCI Host Controller
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
00:14.2 RAM memory: Intel Corporation Cannon Lake PCH Shared SRAM (rev 10)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. Cannon Lake PCH Shared SRAM
00:14.3 Network controller: Intel Corporation Cannon Lake PCH CNVi WiFi (rev 10)
DeviceName: Onboard - Ethernet
Subsystem: Intel Corporation Wireless-AC 9560
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
00:15.0 Serial bus controller: Intel Corporation Cannon Lake PCH Serial IO I2C Controller #0 (rev 10)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. Cannon Lake PCH Serial IO I2C Controller
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
00:16.0 Communication controller: Intel Corporation Cannon Lake PCH HECI Controller (rev 10)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. Cannon Lake PCH HECI Controller
Kernel driver in use: mei_me
Kernel modules: mei_me
00:1d.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #9 (rev f0)
Subsystem: Razer USA Ltd. Cannon Lake PCH PCI Express Root Port
Kernel driver in use: pcieport
00:1d.4 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #13 (rev f0)
Subsystem: Razer USA Ltd. Cannon Lake PCH PCI Express Root Port
Kernel driver in use: pcieport
00:1e.0 Communication controller: Intel Corporation Cannon Lake PCH Serial IO UART Host Controller (rev 10)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. Cannon Lake PCH Serial IO UART Host Controller
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
00:1f.0 ISA bridge: Intel Corporation HM470 Chipset LPC/eSPI Controller (rev 10)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. HM470 Chipset LPC/eSPI Controller
00:1f.3 Audio device: Intel Corporation Cannon Lake PCH cAVS (rev 10)
DeviceName: Onboard - Sound
Subsystem: Razer USA Ltd. Cannon Lake PCH cAVS
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel, snd_soc_skl, snd_sof_pci_intel_cnl
00:1f.4 SMBus: Intel Corporation Cannon Lake PCH SMBus Controller (rev 10)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. Cannon Lake PCH SMBus Controller
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
00:1f.5 Serial bus controller: Intel Corporation Cannon Lake PCH SPI Controller (rev 10)
DeviceName: Onboard - Other
Subsystem: Razer USA Ltd. Cannon Lake PCH SPI Controller
Kernel driver in use: intel-spi
Kernel modules: spi_intel_pci
01:00.0 VGA compatible controller: NVIDIA Corporation TU106M [GeForce RTX 2070 Mobile] (rev a1)
Subsystem: Razer USA Ltd. TU106M [GeForce RTX 2070 Mobile]
Kernel driver in use: nvidia
Kernel modules: nouveau, nvidia_drm, nvidia
01:00.1 Audio device: NVIDIA Corporation TU106 High Definition Audio Controller (rev a1)
Subsystem: Razer USA Ltd. TU106 High Definition Audio Controller
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
01:00.2 USB controller: NVIDIA Corporation TU106 USB 3.1 Host Controller (rev a1)
Subsystem: Razer USA Ltd. TU106 USB 3.1 Host Controller
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
01:00.3 Serial bus controller: NVIDIA Corporation TU106 USB Type-C UCSI Controller (rev a1)
Subsystem: Razer USA Ltd. TU106 USB Type-C UCSI Controller
Kernel driver in use: nvidia-gpu
Kernel modules: i2c_nvidia_gpu
02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
Subsystem: Samsung Electronics Co Ltd SSD 970 EVO
Kernel driver in use: nvme
Kernel modules: nvme
03:00.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
Subsystem: Razer USA Ltd. JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016]
Kernel driver in use: pcieport
04:00.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
Subsystem: Razer USA Ltd. JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016]
Kernel driver in use: pcieport
04:01.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
Subsystem: Razer USA Ltd. JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016]
Kernel driver in use: pcieport
04:02.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
Subsystem: Razer USA Ltd. JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016]
Kernel driver in use: pcieport
05:00.0 System peripheral: Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016] (rev 02)
Subsystem: Razer USA Ltd. JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016]
Kernel driver in use: thunderbolt
Kernel modules: thunderbolt
3b:00.0 USB controller: Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] (rev 02)
Subsystem: Razer USA Ltd. JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pcifind /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-42s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
avahi-daemon.service | multi-user.target.wants
avahi-daemon.socket | sockets.target.wants
dbus-org.freedesktop.Avahi.service | system
dbus-org.freedesktop.nm-dispatcher.service | system
dhcpcd@enp0s20f0u3u4.service | multi-user.target.wants
display-manager.service | system
expressvpn.service | multi-user.target.wants
getty@tty1.service | getty.target.wants
ip6tables.service | multi-user.target.wants
iptables.service | multi-user.target.wants
NetworkManager.service | multi-user.target.wants
NetworkManager-wait-online.service | network-online.target.wants
p11-kit-server.socket | sockets.target.wants
pipewire-session-manager.service | user
pipewire.socket | sockets.target.wants
pulseaudio.socket | sockets.target.wants
remote-fs.target | multi-user.target.wants
wireplumber.service | pipewire.service.wants
xdg-user-dirs-update.service | default.target.wantsexpressvpn preferences
auto_connect true
block_trackers false
desktop_notifications true
disable_ipv6 true
lightway_cipher auto
network_lock default
preferred_protocol auto
send_diagnostics falseexpressvpn diagnostics
Client Version: 3.50.0
Client Shared Version: v23.21.0
OS Name: linux
OS Version: Arch Linux
Internal diagnostics data:
D01: 447, OK
D02: 2843, OK
D03: 445
D04: 9486, OK
D05: 9486, OK
D06: 445
D07: 1045, OK
D08: 1045, OK
D09: 4625, OK
D10: 1645, OK
D11: 1645, OK
D12: N, 2831
D13: www.2spb2qq8pnqmv.net/api
D14: Australia - Sydney - 2
D15: auto
D16: PjA2KGWAoMxmZmZmZmZmZmZmZmZmZmZmZmZ3ZmZ2ZkpqdnYRERFIFBIED1MSBwtIBQkLERERSA4KCFANHFBRSAUJC2ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZg==
D17: 1045
D18: 0
Network Lock: enabled, allow access to local devices
DNS leak protection: enabled
IPv6 leak protection: enabled
Selected location: Australia - Sydney - 2 (Smart Location)
==============================================
Connecting to Australia - Sydney - 2, ip: 128.249.181.99, protocol: lightway_udp
Client Version: 3.50.0
Client Shared Version: v23.21.0
OS Name: linux
OS Version: Arch Linux
Internal diagnostics data:
D01: 12, OK
D02: 11, OK
D03: 10, OK
D04: 6654, OK
D05: 6654, OK
D06: 10, OK
D07: 13, OK
D08: 13, OK
D09: 1793, OK
D10: 1193, OK
D11: 1193, OK
D12: N, N
D13: www.2spb2qq8pnqmv.net/api
D14: Australia - Sydney - 2
D15: auto
D16: PjA2KGWAoMxmZmZmZmZmZmZmZmZmZmZmZmZ3ZmZ2ZkpqdnYRERFIFBIED1MSBwtIBQkLERERSA4KCFANHFBRSAUJC2ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZg==
D17: 593, OK
D18: 0
2023-07-29T13:54:19.164+1000 Loading config data from file: /var/run/expressvpn/config/he3434986027/helium.conf
2023-07-29T13:54:19.164+1000 Lightway: 1.35.0 Lightway Core: 1.10.3 WolfSSL: 5.6.3 libxenon: 1.16.0 libballoon: 1.16.0
2023-07-29T13:54:19.164+1000 Starting tun thread...
2023-07-29T13:54:19.164+1000 Lightway will connect to 128.249.181.99:38349 using protocol: udp, cipher: aes, mtu: 1500
2023-07-29T13:54:19.164+1000 sndbuf: [212992 -> 212992]
2023-07-29T13:54:19.164+1000 rcvbuf: [212992 -> 212992]
2023-07-29T13:54:19.165+1000 Attempting to run tun device '<automatic>'
2023-07-29T13:54:19.165+1000 Initializing tun device...
2023-07-29T13:54:19.165+1000 Lightway is CONNECTING
2023-07-29T13:54:19.166+1000 tun device is up: tun0
2023-07-29T13:54:19.166+1000 81.111.126.145 <----> 81.111.126.146 with DNS server 81.111.126.150 and MTU 1350
2023-07-29T13:54:19.176+1000 Lightway Initial packet received
2023-07-29T13:54:19.193+1000 Link up - took 28.622745ms
2023-07-29T13:54:19.193+1000 Authenticating...
2023-07-29T13:54:19.209+1000 Entered configuring state...
2023-07-29T13:54:19.209+1000 Lightway ONLINE in 44.433084ms
2023-07-29T13:54:19.209+1000 he_execute: starting /usr/sbin/expressvpnd --update-dns-config=static_resolv_conf
2023-07-29T13:54:19.242+1000 he_execute: process exited 0 (signal 0)
2023-07-29T13:54:19.265+1000 Nudging Lightway...
2023-07-29T13:56:56.886+1000 Received signal: 15
2023-07-29T13:56:56.886+1000 Lightway DISCONNECTING...
2023-07-29T13:56:56.886+1000 Lightway DISCONNECTED
2023-07-29T13:56:56.886+1000 Stopping tun thread...
2023-07-29T13:56:56.886+1000 Closing tun device...
2023-07-29T13:56:56.929+1000 Tun thread stopped successfully
2023-07-29T13:56:56.929+1000 he_execute: starting /usr/sbin/expressvpnd --update-dns-config=static_resolv_conf
2023-07-29T13:56:56.949+1000 he_execute: process exited 0 (signal 0)
2023-07-29T13:56:56.949+1000 Lightway DISCONNECTED (disconnect_and_stop).
2023-07-29T13:56:56.949+1000 Lightway STOPPED
2023-07-29T13:56:56.949+1000 Lightway FINISHED
Disconnected with error: network changed
==============================================
Connecting to Australia - Sydney - 2, ip: 128.249.181.99, protocol: lightway_udp
Client Version: 3.50.0
Client Shared Version: v23.21.0
OS Name: linux
OS Version: Arch Linux
Internal diagnostics data:
D01: 170, OK
D02: 169, OK
D03: 168, OK
D04: 6812, OK
D05: 6812, OK
D06: 168, OK
D07: 172, OK
D08: 172, OK
D09: 1951, OK
D10: 1351, OK
D11: 1351, OK
D12: 29, 157
D13: www.2spb2qq8pnqmv.net/api
D14: Australia - Sydney - 2
D15: auto
D16: PjA2KGWAoMxmZmZmZmZmZmZmZmZmZmZmZmZ3ZmZ2ZkpqdnYRERFIFBIED1MSBwtIBQkLERERSA4KCFANHFBRSAUJC2ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZg==
D17: 751, OK
D18: 1
2023-07-29T13:56:57.291+1000 Loading config data from file: /var/run/expressvpn/config/he3167174240/helium.conf
2023-07-29T13:56:57.292+1000 Lightway: 1.35.0 Lightway Core: 1.10.3 WolfSSL: 5.6.3 libxenon: 1.16.0 libballoon: 1.16.0
2023-07-29T13:56:57.292+1000 Starting tun thread...
2023-07-29T13:56:57.292+1000 Lightway will connect to 128.249.181.99:38349 using protocol: udp, cipher: aes, mtu: 1500
2023-07-29T13:56:57.292+1000 sndbuf: [212992 -> 212992]
2023-07-29T13:56:57.292+1000 rcvbuf: [212992 -> 212992]
2023-07-29T13:56:57.292+1000 Attempting to run tun device '<automatic>'
2023-07-29T13:56:57.292+1000 Initializing tun device...
2023-07-29T13:56:57.292+1000 Lightway is CONNECTING
2023-07-29T13:56:57.293+1000 tun device is up: tun0
2023-07-29T13:56:57.293+1000 81.111.126.145 <----> 81.111.126.146 with DNS server 81.111.126.150 and MTU 1350
2023-07-29T13:56:57.303+1000 Lightway Initial packet received
2023-07-29T13:56:57.321+1000 Link up - took 28.023071ms
2023-07-29T13:56:57.321+1000 Authenticating...
2023-07-29T13:56:57.344+1000 Entered configuring state...
2023-07-29T13:56:57.344+1000 Lightway ONLINE in 51.409956ms
2023-07-29T13:56:57.344+1000 he_execute: starting /usr/sbin/expressvpnd --update-dns-config=static_resolv_conf
2023-07-29T13:56:57.366+1000 he_execute: process exited 0 (signal 0)
2023-07-29T13:56:57.392+1000 Nudging Lightway...
2023-07-29T13:57:00.903+1000 Received signal: 15
2023-07-29T13:57:00.903+1000 Lightway DISCONNECTING...
2023-07-29T13:57:00.903+1000 Lightway DISCONNECTED
2023-07-29T13:57:00.904+1000 Stopping tun thread...
2023-07-29T13:57:00.904+1000 Closing tun device...
2023-07-29T13:57:00.930+1000 Tun thread stopped successfully
2023-07-29T13:57:00.930+1000 he_execute: starting /usr/sbin/expressvpnd --update-dns-config=static_resolv_conf
2023-07-29T13:57:00.967+1000 he_execute: process exited 0 (signal 0)
2023-07-29T13:57:00.968+1000 Lightway DISCONNECTED (disconnect_and_stop).
2023-07-29T13:57:00.968+1000 Lightway STOPPED
2023-07-29T13:57:00.968+1000 Lightway FINISHED
Disconnected with error: network changed
==============================================
Connecting to Australia - Sydney - 2, ip: 128.249.181.99, protocol: lightway_udp
Client Version: 3.50.0
Client Shared Version: v23.21.0
OS Name: linux
OS Version: Arch Linux
Internal diagnostics data:
D01: 174, OK
D02: 173, OK
D03: 172, OK
D04: 6816, OK
D05: 6816, OK
D06: 172, OK
D07: 176, OK
D08: 176, OK
D09: 1955, OK
D10: 1355, OK
D11: 1355, OK
D12: N, 162
D13: www.2spb2qq8pnqmv.net/api
D14: Australia - Sydney - 2
D15: auto
D16: PjA2KGWAoMxmZmZmZmZmZmZmZmZmZmZmZmZ3ZmZ2ZkpqdnYRERFIFBIED1MSBwtIBQkLERERSA4KCFANHFBRSAUJC2ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZg==
D17: 755, OK
D18: 1
2023-07-29T13:57:01.314+1000 Loading config data from file: /var/run/expressvpn/config/he2923206569/helium.conf
2023-07-29T13:57:01.315+1000 Lightway: 1.35.0 Lightway Core: 1.10.3 WolfSSL: 5.6.3 libxenon: 1.16.0 libballoon: 1.16.0
2023-07-29T13:57:01.315+1000 Starting tun thread...
2023-07-29T13:57:01.315+1000 Lightway will connect to 128.249.181.99:38349 using protocol: udp, cipher: aes, mtu: 1500
2023-07-29T13:57:01.315+1000 sndbuf: [212992 -> 212992]
2023-07-29T13:57:01.315+1000 rcvbuf: [212992 -> 212992]
2023-07-29T13:57:01.315+1000 Attempting to run tun device '<automatic>'
2023-07-29T13:57:01.315+1000 Initializing tun device...
2023-07-29T13:57:01.316+1000 Lightway is CONNECTING
2023-07-29T13:57:01.316+1000 tun device is up: tun0
2023-07-29T13:57:01.316+1000 81.111.126.145 <----> 81.111.126.146 with DNS server 81.111.126.150 and MTU 1350
2023-07-29T13:57:01.416+1000 Nudging Lightway...
2023-07-29T13:57:01.425+1000 Lightway Initial packet received
2023-07-29T13:57:01.443+1000 Link up - took 127.525704ms
2023-07-29T13:57:01.443+1000 Authenticating...
2023-07-29T13:57:01.474+1000 Entered configuring state...
2023-07-29T13:57:01.474+1000 Lightway ONLINE in 158.259800ms
2023-07-29T13:57:01.474+1000 he_execute: starting /usr/sbin/expressvpnd --update-dns-config=static_resolv_conf
2023-07-29T13:57:01.532+1000 he_execute: process exited 0 (signal 0)
2023-07-29T13:57:01.615+1000 Nudging Lightway...
2023-07-29T14:00:35.539+1000 Sending keepalive...
2023-07-29T14:00:35.543+1000 Lightway Pong received
2023-07-29T14:04:55.543+1000 Sending keepalive...
2023-07-29T14:04:55.547+1000 Lightway Pong received
2023-07-29T14:07:35.546+1000 Sending keepalive...
2023-07-29T14:07:35.551+1000 Lightway Pong received
2023-07-29T14:07:52.736+1000 Sending keepalive...
2023-07-29T14:07:52.741+1000 Lightway Pong received
2023-07-29T14:09:53.900+1000 Sending keepalive...
2023-07-29T14:09:53.904+1000 Lightway Pong received
2023-07-29T14:11:55.550+1000 Sending keepalive...
2023-07-29T14:11:55.555+1000 Lightway Pong received
2023-07-29T14:12:01.544+1000 Lightway secure renegotiation completed
2023-07-29T14:12:01.632+1000 Nudging Lightway...
2023-07-29T14:12:55.555+1000 Sending keepalive...
2023-07-29T14:12:55.559+1000 Lightway Pong received
2023-07-29T14:13:12.233+1000 Sending keepalive...
2023-07-29T14:13:12.238+1000 Lightway Pong received
2023-07-29T14:13:55.561+1000 Sending keepalive...
2023-07-29T14:13:55.566+1000 Lightway Pong received
2023-07-29T14:14:55.566+1000 Sending keepalive...
2023-07-29T14:14:55.571+1000 Lightway Pong received
2023-07-29T14:15:12.402+1000 Sending keepalive...
2023-07-29T14:15:12.407+1000 Lightway Pong received
2023-07-29T14:15:52.680+1000 Sending keepalive...
2023-07-29T14:15:52.685+1000 Lightway Pong received
2023-07-29T14:16:12.442+1000 Sending keepalive...
2023-07-29T14:16:12.447+1000 Lightway Pong received
2023-07-29T14:16:35.566+1000 Sending keepalive...
2023-07-29T14:16:35.570+1000 Lightway Pong received
2023-07-29T14:16:55.563+1000 Sending keepalive...
2023-07-29T14:16:55.568+1000 Lightway Pong received
2023-07-29T14:17:35.570+1000 Sending keepalive...
2023-07-29T14:17:35.575+1000 Lightway Pong received
2023-07-29T14:17:55.568+1000 Sending keepalive...
2023-07-29T14:17:55.573+1000 Lightway Pong received
2023-07-29T14:18:12.571+1000 Sending keepalive...
2023-07-29T14:18:12.576+1000 Lightway Pong received
2023-07-29T14:19:55.563+1000 Sending keepalive...
2023-07-29T14:19:55.568+1000 Lightway Pong received
2023-07-29T14:20:12.175+1000 Sending keepalive...
2023-07-29T14:20:12.179+1000 Lightway Pong received
2023-07-29T14:21:55.575+1000 Sending keepalive...
2023-07-29T14:21:55.580+1000 Lightway Pong received
2023-07-29T14:22:55.580+1000 Sending keepalive...
2023-07-29T14:22:55.584+1000 Lightway Pong received
2023-07-29T14:25:15.474+1000 Sending keepalive...
2023-07-29T14:25:15.479+1000 Lightway Pong received
2023-07-29T14:25:52.942+1000 Sending keepalive...
2023-07-29T14:25:52.946+1000 Lightway Pong received
2023-07-29T14:26:15.578+1000 Sending keepalive...
2023-07-29T14:26:15.583+1000 Lightway Pong received
2023-07-29T14:26:55.587+1000 Sending keepalive...
2023-07-29T14:26:55.592+1000 Lightway Pong received
2023-07-29T14:27:01.544+1000 Lightway secure renegotiation completed
2023-07-29T14:27:01.632+1000 Nudging Lightway...
2023-07-29T14:27:55.577+1000 Sending keepalive...
2023-07-29T14:27:55.582+1000 Lightway Pong received
2023-07-29T14:28:14.766+1000 Sending keepalive...
2023-07-29T14:28:14.771+1000 Lightway Pong received
2023-07-29T14:29:55.588+1000 Sending keepalive...
2023-07-29T14:29:55.593+1000 Lightway Pong received
2023-07-29T14:30:13.774+1000 Sending keepalive...
2023-07-29T14:30:13.778+1000 Lightway Pong received
2023-07-29T14:30:53.265+1000 Sending keepalive...
2023-07-29T14:30:53.270+1000 Lightway Pong received
2023-07-29T14:31:35.586+1000 Sending keepalive...
2023-07-29T14:31:35.591+1000 Lightway Pong received
2023-07-29T14:31:55.599+1000 Sending keepalive...
2023-07-29T14:31:55.603+1000 Lightway Pong received
2023-07-29T14:33:55.595+1000 Sending keepalive...
2023-07-29T14:33:55.599+1000 Lightway Pong received
2023-07-29T14:34:55.601+1000 Sending keepalive...
2023-07-29T14:34:55.605+1000 Lightway Pong received
2023-07-29T14:35:13.708+1000 Sending keepalive...
2023-07-29T14:35:13.713+1000 Lightway Pong received
2023-07-29T14:35:53.931+1000 Sending keepalive...
2023-07-29T14:35:53.936+1000 Lightway Pong received
2023-07-29T14:36:15.603+1000 Sending keepalive...
2023-07-29T14:36:15.608+1000 Lightway Pong received
2023-07-29T14:36:35.599+1000 Sending keepalive...
2023-07-29T14:36:35.604+1000 Lightway Pong received
2023-07-29T14:36:55.596+1000 Sending keepalive...
2023-07-29T14:36:55.600+1000 Lightway Pong received
2023-07-29T14:37:35.605+1000 Sending keepalive...
2023-07-29T14:37:35.610+1000 Lightway Pong received
2023-07-29T14:37:55.602+1000 Sending keepalive...
2023-07-29T14:37:55.606+1000 Lightway Pong received
2023-07-29T14:38:15.598+1000 Sending keepalive...
2023-07-29T14:38:15.602+1000 Lightway Pong received
2023-07-29T14:39:55.612+1000 Sending keepalive...
2023-07-29T14:39:55.617+1000 Lightway Pong received
2023-07-29T14:40:15.609+1000 Sending keepalive...
2023-07-29T14:40:15.614+1000 Lightway Pong received
2023-07-29T14:40:54.573+1000 Sending keepalive...
2023-07-29T14:40:54.577+1000 Lightway Pong receivedLast edited by fractal_sounds (2023-07-29 05:11:11)
Offline
You've dhcpcd and NetworkManager enabled concurrently.
Unless you've configured NM specifically to ignore enp0s20f0u3u4 they'll knock each other out over the device.
=> disable the dhcpcd service.
Also you're apparently using a USB dongle.
lsusb -tvhttps://wiki.archlinux.org/title/Power_ … utosuspend
Adding "usbcore.autosuspend=-1" to the https://wiki.archlinux.org/title/Kernel_parameters will disable that globally, but nb. that powermanagement utils can and typically will alter that at runtime (you don't have TLP enabled, but the fat desktop environments have their own utils)
Offline
You've dhcpcd and NetworkManager enabled concurrently.
Oh my goodness, I feel so silly I didn't realise this myself. I do remember reading on the Network Configuration wiki the warning about having multiple network managers. I selected and installed dhcpcd when I was configuring the system during the initial install. But I guess by the time I got to installing the desktop environment a few days later, I had forgotten about this and didn't realise installing Plasma would have enabled the NetworkManager service, causing the conflict with dhcpcd. Lesson learnt! I've disabled the dhcpcd service and already things feel much more normal. Thank you so much Seth!
Also you're apparently using a USB dongle.
Yes I have a USB hub to provide me with an Ethernet port which my laptop was lacking.
Adding "usbcore.autosuspend=-1" to the https://wiki.archlinux.org/title/Kernel_parameters will disable that globally
Would you recommend I do this anyway, regardless of whether it has any impact on the connectivity issues discussed in this thread? In other words, if your advice regarding the conflict between dhcpcd and NetworkManager resolves the issue with random losses of connection (as it appears to have done so far), is that sufficient? Or would you recommend adding that kernel parameter as a precaution regardless of how things are appearing now?
***********************************
EDIT: I think I spoke too soon. Random dropouts once again occurring. The couple of times it has happened again so far, disabling the VPN brings the connection back immediately. So I am becoming more convinced that something is amiss either with the VPN itself, or how it's interacting with the firewall. Given that I've previously used ExpressVPN on Manjaro with no issues, would you recommend that I abandon the firewall config I performed manually using iptables and starting fresh, perhaps getting the help of a firewall front-end for iptables/nftables?
Last edited by fractal_sounds (2023-07-29 11:16:11)
Offline
Would you recommend I do this anyway
If it doesn't help the situation you're just wasting battery. Also the global parameter is the broadsword approach and mostly useful for investigating the cause of troubles. You'd go w/ a specific rule afterwards.
A static firewall will not lead to random connectivity drops.
wrt VPNs the usual suspect is the MTU
ip link set dev enp0s20f0u3u4 mtu 1280 # the NIC is an assumption from your dhcpcd service, check "ip l"The default MTU is 1500, 1280 is kinda very much lowballing this, if it stabilizes the VPN, you can move this (much higher), eg. 1460 and see whether the VPN remains stable.
Offline
A static firewall will not lead to random connectivity drops.
Ah I see! Good to know, thank you. I really need to invest some time eventually and learn more about firewall fundamentals.
The default MTU is 1500, 1280 is kinda very much lowballing this, if it stabilizes the VPN, you can move this (much higher), eg. 1460 and see whether the VPN remains stable.
Thank you very much Seth. I will experiment with this setting over the next couple of days and report back.
I'm also going to modify the title of this thread (for more useful future search) to reflect the fact that the issue appears to be VPN-related.
Offline
The default MTU is 1500, 1280 is kinda very much lowballing this, if it stabilizes the VPN, you can move this (much higher), eg. 1460 and see whether the VPN remains stable.
Experimenting with different values for the MTU didn't improve the situation, unfortunately.
After some more searching around, I believe I may have found a solution. On ExpressVPN's troubleshooting pages, one of the things they recommend for the situation I was experiencing was trying other protocols, rather than the default Automatic one.
If you are unable to connect to ExpressVPN with the Automatic protocol, try the other protocols in the following order (if available):
Lightway – TCP
Lightway – UDP
OpenVPN – TCP
OpenVPN – UDP
IKEv2
As soon as I tried the first option (Lightway TCP), the VPN connected successfully almost immediately (up to that point I had been having an extended run of not even being able to connect to the VPN server). And so far I've had an entire day of usage with zero dropouts. I'm fairly sure this will be a viable long-term solution for this issue, and I'm going to mark this thread as solved.
Thank you very much again for all your assistance Seth, I truly appreciate it.
Offline