So the solution turned out to be twofold: First, I added this to pf.conf: pass in proto udp to any port 30000
Then add this line to minetest.conf: bind_address = 0.0.0.0 On Sun, Jun 7, 2026 at 7:32 AM Polarian <[email protected]> wrote: > Good morning, > > > here is the output of pfctl -s rules: > > block return all > > pass all flags S/SA > > block return in on ! lo0 proto tcp from any to any port 6000:6010 > > block return out log proto tcp all user = 55 > > block return out log proto udp all user = 55 > > block return all > > pass all flags S/SA > > block return in on ! lo0 proto tcp from any to any port 6000:6010 > > block return out log proto tcp all user = 55 > > block return out log proto udp all user = 55 > > pass in proto tcp from any to any port = 30000 flags S/SA > > Yeah you have duplicated rules, you really should clean up your pf.conf > first. > > Secondly, passing the packet flow in my brain, I do not see where the > packet could be dropped. > > block return all (expanded from block return) is a default block all but > its immediately followed by a pass all which would allow network in > both in and out. > > the further blocks are port and user specific so wouldn't affect a > packet with port 30000 apart from the final line, but thats a > pass rule so it would still pass. > > Are you should luanti is bound to port 30000? nmap on localhost can be > useful (remember you are skipping loopback, so nmap on loopback is a > quick way to see) and then if you do see 30000 bound to, then try on a > remote machine, see what ports pop up. > > Also I strongly recommend you modify your config to be block in and > pass out, you can then remove the xorg lines because the default block > in will protect against xorg being exposed (unless you explicitly allow > it through) and you can keep the build server network isolation lines. > > Apart from the apparent mess of your pf.conf, I don't see how pf would > match a block rule against a tcp packet on port 30000. > > As suggested by Paul, I would do block log in (you can add return if you > like) and keep pass out under it, then tcpdump -nettti /dev/pflog0 and > then see if pf is actually blocking packets to port 30000, if nothing > shows up on the pflog interface you know pf is not the issue here, if > it is then you know the pass rule isn't matching, maybe provide the > output of tcpdump so that someone here can help you debug. > > Hope this helps. > > Take care, > -- > Polarian > Jabber/XMPP: [email protected] > >
