I am only a few months young into my Archlinux journey. So far I was able to solve most problems by myself ("The Arch way?") but I have one particular issue that I am not figuring out and where research or asking AI is also no yielding any working solutions.

I try to use Wireguard VPN (either through proton-vpn-gtk-app or directly through wg-quick) to appear with a different IP in the internet through Proton VPN. However, after connecting I am unable to access the internet, while the VPN believes it is connected and failing the keep-alive a few minutes later, forcing a reconnect. OpenVPN works just fine. While I could just leave it at that, I try to understand what is going wrong and perhaps take my learnings from it.

I tested pinging both towards domains and IP-adresses to rule out DNS as a cause since that has been an issue in the past. After that I looked into whenever my Firewall Configuration may be the cause. Easy enough, disabling iptables temporarily through systemctl stop iptables ip6tables allows WireGuard to work successfully. This suggests that the cause may be some bad iptables rules in the INPUT/OUTPUT/FORWARD chain. Trying to debug this though not let to anything reasonable.

My current iptables configuration is based of the Simple stateful firewall in the ArchWiki:

-P INPUT DROP -P FORWARD DROP -P OUTPUT ACCEPT -N TCP -N UDP -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP -A INPUT -p udp -m recent --set --name UDP-PORTSCAN --mask 255.255.255.255 --rsource -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -m recent --set --name TCP-PORTSCAN --mask 255.255.255.255 --rsource -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable -A TCP -p tcp -m recent --update --seconds 60 --name TCP-PORTSCAN --mask 255.255.255.255 --rsource -j REJECT --reject-with tcp-reset -A UDP -p udp -m recent --update --seconds 60 --name UDP-PORTSCAN --mask 255.255.255.255 --rsource -j REJECT --reject-with icmp-port-unreachable -A UDP -p udp -m udp --dport 5353 -j ACCEPT 

A trivial first step would be to accept the ports related to the Wireguard connection here similar to how I accepted 5353 for Multicast DNS before. This didn't work however, which is why I proceeded to log packages towards kernel logs by using iptables -I INPUT 1 -j LOG --log-prefix "..." for all packages entering the INPUT chain, or iptables -I INPUT 2 -j LOG --log-level-prefix "..." for all packages making it past the initial accept of already related or established connections. Those can then be seen in journalctl -k -f. I can see the packages from the VPN interface there, but almost all of them are already part of the related/established connection and are getting accepted. The only package that makes it through is of ICMP Type 8, which happens to be accepted. I can confirm this by looking at the package numbers displayed for individual entries in iptables -nvL. Furthermore, I can use that confirm that no packages reach or were dropped by the FORWARD Chain, ruling it out as the verdict as well.

As such, it appears that all packages sent through the INPUT and OUTPUT chain are being accepted, leaving me clueless on why the connection fails (and only if iptables is currently running).

This was the moment where I started messing around with OpenVPN, just to find out that it works just fine. Using wg-quick to start the wireguard connection instead confronted me with yet new concepts for me:

[#] ip link add dev Naberius-CH-433 type wireguard [#] wg setconf Naberius-CH-433 /dev/fd/63 [#] ip -4 address add 10.2.0.2/32 dev Naberius-CH-433 [#] ip link set mtu 1420 up dev Naberius-CH-433 [#] resolvconf -a Naberius-CH-433 -m 0 -x [#] wg set Naberius-CH-433 fwmark 51820 [#] ip -6 rule add not fwmark 51820 table 51820 [#] ip -6 rule add table main suppress_prefixlength 0 [#] ip -6 route add ::/0 dev Naberius-CH-433 table 51820 [#] ip6tables-restore -n [#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 [#] ip -4 route add 0.0.0.0/0 dev Naberius-CH-433 table 51820 [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 [#] iptables-restore -n 

Researching them suggests to me that this is what WireGuard uses to create it's interface and ensuring that Non-WireGuard traffic (the one that isn't necessairy to keep the connection to the WireGuard Server established) is going through the VPN Tunnel, which is.. expected behavior? Looking up what the individual commands do and what the endgoal of all of this is not brought me any closer to finding any oddities that could explain what is going on here.

Attempts to research this behavior (or asking AI) keeps pointing back at how the IPtables Rules must be messed up in one way or another, which is extensively tested towards the point of temporarily having everything accepted at the very top of the INPUT chain, just for the issue to persist. Either I fundamentally understand something wrong in Iptables, or there is some other issue there I fail to find and understand here. And since i can't rule out that this isn't specific to the VPN Provider but to how I did setup Wireguard (or anything networking) on this system, I figured it would probably be a good idea to get this solved before I need it for something more urgent like using a VPN in the intended way (creating a private network to other machines).

Some other things I looked into: - systemd-networkd is disabled as I run NetworkManager. - systemd-resolved is running and I am not sure if it conflicts with NetworkManager (I don't think so?). I disabled features such as DNSoverTLS during testing, just to be sure that this was not the cause.