homelab

7595 readers

2 users here now

founded 4 years ago

MODERATORS

[email protected]

Firewall rules not working as expected (lemmy.world)

submitted 4 months ago by [email protected] to c/[email protected]

5 comments fedilink hide all child comments

I have a couple rules in place to allow traffic in from specific IPs. Right after these rules I have rules to block everything else, as this firewall is an "allow by default" type.

The problem I'm facing is that when I replace these two ports to match "Any" instead, those machines (matrix server and game server) are unable to perform apt-gets.

I had thought that this should still be allowed, because the egress rules for those two permit outbound traffic to http/s and once that's established it's a "stateful" connection which should allow the traffic to flow back the other way.

What am I doing wrong here, and what is the best way to ensure that traffic only hits these servers from the minimal number of ports.

top 5 comments

sorted by: hot top controversial new old

[–] [email protected] 4 points 4 months ago (1 children)

It probably causes all traffic that would be NAT'd out now gets a port forward which breaks the connection because it treats the returning SYN as a new connection which creates a new port mapping that's incompatible with the original outgoing SYN, and it fails.

Try allowing all ports <10000 or something like that, you'll likely observe it works again.

You need to allow all established traffic before the any rules without further processing, or at least that's how it is with iptables. No idea what interface that is but if it's OpenWRT, it does become iptables under the hood.

[–] [email protected] 4 points 4 months ago* (last edited 4 months ago)

When you make an outgoing connections, its source is a random local port in the 30000+ range or something like that, and when the remote server replies, it replies back on that port. But if your rules then treat the response to that port as a port forward rule, it won't reach the NAT rule that would remangle the packet in the correct way to preserve the connection.

So, server wants to go out and uses port 33333, router NATs it and rewrites it as outgoing from your public IP from say, 44444, then the remote server replies back, and the router just sends the 44444 to your server as-is because port forward, and your server's like, I don't know anyone interested in port 44444 and drops it, while the client is waiting on port 33333 to hear back and never does, until it times out.

In iptables terms, that's what --cstate ESTABLISHED,RELATED handles and why you see it in NAT examples.

[–] EmoPolarbear 4 points 4 months ago (1 children)

You probably need an “allow established rule” not familiar with the interface youre using so i cant guide you mich further than that

[–] [email protected] 1 points 4 months ago

Ah, would this be a separate rule, or (as I’m using Ubiquiti) I could check “established” and/or “related” on either the allow or block rule?

[–] [email protected] 1 points 4 months ago

Are you able to, say, wget 1.1.1.1?

Maybe it's just DNS, since it's UDP based there is no state, although some firewalls do detect requests and treat it as pseudo-stateful.