Subtle distinctions between similar UFW commands

Staking & Delegation Operate a Stake Pool
1

I’m setting up simple ufw rules on my cloud instances, but coincashew’s guide has used the command:

ufw allow 22/tcp

Let h:p indicate host:port# a service is running on.

The IPv4 output of this command, ufw allow 22/tcp, looks like…

To------------------------Action-------------From
22/tcp----------------ALLOW IN-----Anywhere

So, I interpret this as one-way communication filter allowing tcp traffic: any:any to my.local.node:22

When I was experimented with UFW commands before, one of them that I created for SSH took the form…

ufw allow proto tcp from any to any port 3001, but the output for this command looks like:

To-------------Action---------From
22/tcp------ALLOW----Anywhere

The distinction between the two commands is highlighted.

To me the second command is slightly more general allowing two way traffic: tcp traffic flow in: any:any to my.local.node:22 and tcp traffic flow out: any:any to my.local.node:22. In the latter case this allows for feedback loop communication, like 127.0.0.1:any to 127.0.0.1:22 as well as any.LAN.host:any to my.local.node:22. Is this a correct interpretation?
Or is it even more general than that?: any.LAN.host:any to any.host:22, local (LAN) or otherwise (www)?

Any ideas on which interpretation if any for the second command is correct?

2

UFW is state-full firewall, it means that an SSH TCP connection, despite it send and receive packets in both direction, is handled as a whole. So it simply means in your context that allow in would allow only incoming SSH connections to your server only (even if you have multiple IP addresses, foer example to ssh to localhost/127.0.0.1 would be accepted by UFW but of course sshd should listen on that IP:sshport). Allow, accepts SSH connection initiated both way, from your server to any to any to your server. It is more complex as it is based on iptables which has 3 default tables, but it is not important as UFW was developed to eliminate the complexity of iptables.

1 Like
3

So the easiest way is to check with iptables -L how both are confiured, cos I have not checked. As UFW means uncomplicated firewall to hide iptables complexity.

1 Like
4

Thanks for your help. I appreciate it. If you’re familiar with GCE VMs, they have a feature to allow you to create just about any type of connectivity test to test firewall rules to see if traffic can flow “through your rules” from one start point before the first rule to the endpoint after last rule.
Is there an analogous CLI package including iptables in linux that has a feature/flag similar to GCE VM’s connectivity test that produces output similar to it in CLI form? - I prefer it over GUIs, the extra complexity of GUIs means more failures in theory and in practice as well, as I’ve learned from past experiences:

firewall-test