On Fri, 11 Oct 2024, at 7:40 AM, Martin Brampton wrote: > Thanks, I'm sure that makes sense. But I'm on the point of abandoning > the use of nftables with openvpn. I've already spent several days on > this. Other servers (about 15 in all) are running with nftables, and I > would prefer total consistency, but not at any price. > > When I say can't access any services, I mean literally that. I can > create a new server, install openvpn, connect to it and use services > like ssh, mosh, https, imaps... And I can do that with an iptables firewall. > > But as soon as I add nftables (removing iptables) and connect to the > server as a VPN, mosh sessions stop, web access ceases, mail access > ceases. Given that the ruleset opens all output ports, on the face of > it, that should not happen. > > And from that point I cannot find any way back to a working VPN server, > which makes testing harder, and is disastrous for a live VPN server. I take it that there is no out-of-band management system in place for the affected server? If so, you might consider whether the kernel is panicking. Given the use of Debian 12, it would be surprising but by no means impossible. You can test rulesets more safely by using tmux or GNU screen and running "nft -f /path/to/ruleset; sleep 10; nft flush ruleset". Assuming that you are able to access the server after the ruleset has been flushed, there would be no practical impediment to tracing as a debugging method. -- Kerin Millar
