Nftables blocking MineOS webUI from receiving server stats

Connectivity
1

Hello there,

I’ve set up a public vanilla 1.20.1 server on MineOS Turnkey hosted on a Proxmox VM. Everything seems to work great apart from my firewall config. I’ve followed the steps on the wiki for setting up nftables, but something in there is blocking WebUI from fetching the server’s status. I know it’s just my firewall having issues because when I disable nftables, webUI can update the server stats again.

Below is what’s inside my /etc/nftables.conf:

#!/usr/sbin/nft -f

flush ruleset

table inet pkt_filter {
    chain inbound {
        type filter hook input priority 0; policy drop;

        ct state { related, established } accept
        tcp dport { ssh } ct state { new } accept
        # allow 8443 (mineos webui) through
        tcp dport { 8443 } ct state { new } accept
        # allow 25565 (VanillaMC server) through
        tcp dport { 25565 } ct state { new } accept
        #icmp, rate limited
        icmp type { echo-request } limit rate 4/second accept
        icmpv6 type { echo-request } limit rate 4/second accept
        # accept localhost traffic
        iif lo accept
        # reject trash traffic
        ct state { invalid } drop
        tcp flags & (fin|syn|rst|ack) != syn ct state { new } drop
        # log all remaining packets
        ip protocol { tcp } counter log prefix "tcp.in.dropped: "
        ip protocol { udp } counter log prefix "udp.in.dropped: "
    }
    chain outbound {
        type filter hook output priority 0; policy drop;

        ct state { related, established } accept
        #allow dns resolution for the host
        udp dport { 53 } accept
        # initiate outbound connections http/https
        tcp dport { http, https } accept
        #log all remaining packets
        ip protocol { tcp } counter log prefix "tcp.out.dropped: "
        ip protocol { udp } counter log prefix "udp.out.dropped: "
    }
}

Note: I’m very new to nftables and networking in general.

3

Start with the logs. In the logs you’ll see all the unmatched (dropped) packets show up with the prefix “tcp.in.dropped”/“udp.in.dropped”. Among those packets dropped will be ones that are recognizably for the server status.

Are you able to grep out your logs so that you can see all the dropped packets? We can transform that log entry into an ALLOW rule.

Also,you can do incremental opening of the firewall. Instead of testing it ON/OFF and determining that “the firewall is blocking it”, we can instead turn off the “DROP” policy for in or out. Whichever one makes the server status work, tells us which direction the firewall is impeding.

4

Yes I’m able to grep the logs (with the help of the wiki again).

On the inbound TCP side, it’s dropping a connection between my PC (the source) and the webUI (the destination) via port 25565 and on the inbound UDP side, it’s dropping a connection between my PC (the source) and the broadcast address (the destination).

To turn off the “DROP” policy, I change one of these lines from “drop” to “accept”, right?

type filter hook input priority 0; policy drop;
type filter hook output priority 0; policy drop;
5

Assuming these were the correct lines to change, it was effectively the “out” part that was blocking webUI from accessing the query.

So… what exactly do I allow?

EDIT: I figured it out; I just had to allow outbound traffic from the server.

For future reference:

# allow query via 25565
tcp dport { 25565 } accept

Thank you for nudging me in the right direction though, I really appreciate it :smiley:

1 Like