nope, unfortunately it’s all the same. I can’t figure out how to interpret that message in the first place. On one hand it shows the icmp traffic on the local interface’ OUTPUT chain, on the other hand – the DNS traffic between client and the server wrapped up in brackets… this is beyond my understanding of the iptables…
Thanks again. This didn’t work either. But you’ve mentioned the vpn traffic before. And this is my vpn server machine, so I think I should do some more digging.
One thing I’ve noticed is nslookup uses 127.0.0.53 for dns server, while the real dns server is on a separate host on the network. I think vpn setup has to do something with this…
It will take me a while to figure this all out.
the host is running openvpn with pretty standard config:
server 10.xxx.yyy.zzz 255.255.255.mmm <<-- server ip & mask
push “redirect-gateway def1 bypass-dhcp”
push “dhcp-option DNS 192.168.aaa.bbb” <<-- router ip address
keepalive 10 120
tls-auth ta.key 0
As as side note, dns also uses tcp, so better open udp and tcp for port 53.
Since those rules are processed in a way which can be called “first match wins”, you may reconsider to put some of the DROP rules after the ACCEPT targets.
If you want to see what effectively is happening, you’d better use iptables -nvL. There you can see where traffic succeeds and where it is dropped.
However, I do not know how it collides with nftables.
Occasionally nftables may not see everything.
Fedora now uses a systemd-resolve.service. systemctl status systemd-resolved.service
To see its config: resolvectl
If you would open your outgoing traffic anyway, you can use firewalld as well.
Of cause, there is more control using own rulesets, but also a bigger chance of misconfiguration, such as forgetting to configure ip6tables at all and so on. However using firewalld with firewall-cmd can be very secure and practical. There also is a way to define “rich rules” that are way more specific. So breaking with old habits can be rewarding. Or in case one just starts with writing firewalls, then better start with nftables or firewalld rather than iptables.
Note that iptables is virtually deprecated and should be replaced with nftables.
In addition, it is much easier to generate a safe and working configuration with firewalld.
So, it is best not to disable firewalld, but rather utilize it for a high-level firewall setup.
True, it does force all traffic via vpn. And that is intentional.
The long story short, the current setup does its job reasonably well (as a vpn server) when machine is connected on dmz side of the network. My problem was that dnf upgrade wouldn’t work. So whenever I wanted to upgrade I’d connect the machine to the internal network and run dnf upgrade.
Unfortunately, it stopped working even from within at some point. And I don’t have much time to look into this. It’s my home project anyway.
What’s concerning me, is the transition from iptables to nftables. Not sure how much of an effort is to convert all the scripts from one to another, but I’ll have to come back to it sooner or later.