You are not logged in.
Pages: 1
In a game, I get errors that it cannot connect to voice. I have just the default nftables running. It works if I disable it.
How can I find what it is blocking?
How do I unblock it?
Please don't ask me to install some bloat.
Offline
https://gitlab.archlinux.org/archlinux/ … type=heads
The default shipped nftables config allows only you to establish connections to others but not the other way around.
https://bbs.archlinux.org/viewtopic.php … 7#p2309667
users frequently just enable that and wonder why their server isn't reachable…
The game might have published a list of ports you must allow on their website, sometimes...
Otherwise there is nftables logging which I've never tried.
To unblock it, add the port to the config in /etc/nftables.conf (once you found the port).
Or just disable nftables. Even in Fedora, the default rule (of firewalld) is allowing any port >1024.
p.s. I'm guessing the voice is P2P, requiring you to be able to be connected by other players.
Last edited by Beemo (Yesterday 14:11:56)
Offline
Does this look correct? Because it doesn't fix the problem.
$ sudo nft list ruleset
table inet filter {
chain input {
type filter hook input priority filter; policy drop;
ct state invalid drop comment "early drop of invalid connections"
ct state { established, related } accept comment "allow tracked connections"
iif "lo" accept comment "allow from loopback"
meta l4proto { icmp, ipv6-icmp } accept comment "allow icmp"
tcp dport 22 accept comment "allow sshd"
meta pkttype host limit rate 5/second burst 5 packets counter packets 0 bytes 0 reject with icmpx admin-prohibited
counter packets 24 bytes 2091
tcp dport 3724 accept
udp dport 3724 accept
}
chain forward {
type filter hook forward priority filter; policy drop;
}
}Offline
Not sure. There is not enough information for me to tell.
Based on the port, this is what I found: https://eu.forums.blizzard.com/en/wow/t … all/401644
If the game uses dynamic port you might be out of luck and have to allow port > 1023, as there isn't something similar to Windows' allowing specific applications through firewall (afaik).
tcp dport 1024-65535 accept
udp dport 1024-65535 acceptOffline
Well, even when I set it to:
tcp dport 1-65535 accept
udp dport 1-65535 acceptIt still doesn't work.
Offline
Which game? Don't bother, have you tried putting your allowed incoming-port rules above the reject/drop rule? In the ruleset you posted, the reject comes before the tcp/udp dport 3724 accept rules, so packets hitting that reject won't reach those accepts...
Edit:
How can I find what it is blocking?
temporarily replace the reject rule w/ a counter + log so you can see what's being blocked, then journalctl -k -f (or dmesg -w) and watch what shows up when you try to connect to voice...
Last edited by 5hridhyan (Yesterday 18:42:41)
Offline
Did you reload the config?
$ sudo nft flush ruleset
$ sudo systemctl restart nftables.serviceVery unlikely: if the voice chat is using some niche protocol (instead of tcp/udp) then the current rule doesn't cover it, and it might also confuse the connection tracker used in the "ct ..." rule. But to tell that you'd need to packet capture with the firewall off.
Offline
Please don't ask me to install some bloat.
Pick your poison.
https://wiki.archlinux.org/title/Uncomplicated_Firewall
https://wiki.archlinux.org/title/Wireshark
You'll have to understand the traffic you want to filter - it's frankly weird enough that this doesn't operate on conntrack.
Also the order of the rules matters - maybe you want to put it with the rest of the fire?
Offline
(face palm) I just finally noticed the accept is placed after the reject rule, it should be:
tcp dport ssh accept comment "allow sshd"
tcp dport 3724 accept
udp dport 3724 accept
pkttype host limit rate 5/second counter reject with icmpx type admin-prohibitedThe last line rejects the first 5 packets in a second with "admin prohibited", so it's going to mess with the connection if it's before the accept rule.
(Can't believe I zoned out on this line even tho I'm using it in my config...)
Last edited by Beemo (Yesterday 20:24:07)
Offline
Yes, it is the order at fault. I added the rules by command first but when I edited the /etc/nftables.conf file and put it above the line with policy drop, it works.
Now, I have to figure out the ports because 3724 is not enough.
temporarily replace the reject rule w/ a counter + log
You have to be more explicit. How should I change this?
pkttype host limit rate 5/second counter reject with icmpx type admin-prohibitededit: I tried putting log after counter but nothing shows up in dmesg
Last edited by Worstarchuser (Yesterday 21:10:09)
Offline
You have to be more explicit. How should I change this?
I hope despite Beemo's spoiling efforts you still clicked on the Meme and trust you are going to watch the IT-Crowd.
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
PS: you understand that the "bloat" exists precisely to make this accessible to users who do not read manpages?
Offline
5hridhyan wrote:
temporarily replace the reject rule w/ a counter + log
You have to be more explicit. How should I change this?
pkttype host limit rate 5/second counter reject with icmpx type admin-prohibitededit: I tried putting log after counter but nothing shows up in dmesg
Hey, your search engine would have been more explicit than me.
Again, don't bother. You don't need to replace or edit that reject line directly, just add a separate log rule above it.
Last edited by 5hridhyan (Yesterday 21:28:15)
Offline
Pages: 1