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.
On 10/10/2024 20:56, Kerin Millar wrote:
>
> In your initial post, you describe your problem as not being able to access any services. That does not amount to a concrete description of a test case. Upon your peer being connected, what exactly have you tried where the outcome is not as expected? What were the diagnostic messages reported, if any? If you were to focus on - and detail - a particular scenario, it could make it easier for other readers to help you diagnose the underlying problem.
>
> Additionally, you may find it beneficial to define a rule that enables the nftrace mode for packets of interest. That is, those that you suspect are being erroneously dropped. I usually do so in a prerouting hook. For example:
>
> chain prerouting {
> type filter hook prerouting priority raw; policy accept;
>
> # Trace any TCP packet arriving that is destined for port 22 at any host
> tcp dport 22 meta nftrace set 1
> }
>
> You may then run "nft monitor trace" and observe the trajectory of the packet(s) through your ruleset in real time.
>
