@bluedawg Did you try IP-Port Group but put in the whole port range 1-65535? Maybe just the port number or IP address not correct

  @Somnus I did -i tried both individual ip addresses  /32 and the full subet /24.    either of those work as long as the port is only specified on one end. 

  @bluedawg -oops -misunderstood what you were saying -tried the subnet range but not the full port range -i guess that would test if its the ip-port-group function vs. just the specific port chosen.  will give it a test and let you know

@bluedawg,

It's my undersanding that the ssh client uses a random port on the client to connect to port 22 (by default) on the server.

SSH client side port - Stack Overflow

By setting a bi-directional rule from clients:22 to servers:22, I suspect you are blocking that traffic.

I'm assuming you're connecting via IP. Otherwise you're going to need other traffic going thru.

  @EricPerl  I was a bit confused thru my trials of what worked and what didn't.  What works is for my admin computer to connect to the client via ssh:

SRC: network or IP-group (but no port-specified) to DST: IP-port-group (bi-directional)

So your explanation make sense -the initiating request can come from any port and is random, whereas the client connection is 22/tcp.  Thanks!

that helps with a similar acl problem i was having

@bluedawg,

You can check the client port within a ssh session by using the following command:

env | grep SSH_CON
This will output the client ip & port following by the server ip & port (at least on Ubuntu 22.04).

If you find a reply helpful, you might as well mark it as such (little upward triangle towards the bottom right).

  @EricPerl  that was a no go on Linux Mint (which i thought was Ubuntu) and RPi (Debian?) but following your suggestion I found another:

sudo netstat -tnpa | grep 'ESTABLISHED.*sshd'

this returns the active ssh connection by ip and port.  ran this a few times with ssh connections and yep -initiating computer used a different port every time usually ~39680

fwiw, I was a little worried that by configuring the ACL rule as such:

SRC: admin

DST: IP-port group

that the reverse rule created to keep it bidirectional (bc omada isn't stateful), may leave my admin computer vulnerable to a device on the IP-port group trying to connect.  that doesn't seem to be the case -at least trying to connect via ssh -probably bc of the same reason -initiating computer, in this case RPi, is using a different port and it's not allowed bc it isn't specified in the ACL rule (even if allowed thru the ufw firewall on the admin computer)

@bluedawg ,

I'm still relatively new to the Linux space. I'm way more comfortable on the Windows side...

I'm still amazed at the variability across distros.

In this case, it appears that the environment variables in question are OpenSSH specific!

eric@server:~$ env | grep SSH
SSH_CONNECTION=10.1.1.8 64776 10.1.1.123 22
SSH_CLIENT=10.1.1.8 64776 22

That's a little easier than going thru the netstat output :-)

I'll play with ACL rules later.

During my first attempts, I managed to lock myself out of the controller (one situation where having a software version would make things easier).

I think I'll stay away from bi-directional rules. Instead, I'll focus on what a set of sources can and cannot do...