ACL rule question -between my management computer/network and clients

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

ACL rule question -between my management computer/network and clients

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
ACL rule question -between my management computer/network and clients
ACL rule question -between my management computer/network and clients
2022-06-21 22:06:55
Hardware Version: V5
Firmware Version:

setup ER605, TL-SG-2008P, EAP615-wall, omada controller software v5 on linux

4 VLANs

1 -management/admin

10-laptops

20-devices like phones

30-raspberry pis

 

I've noticed the following when setting up rules between my management computer/network and clients (rpi) i need to access:

setting source to IP-port-group and destination to IP-port-group for allowing traffic (bi-directional) between clients (on separate VLANs) such as 22/tcp for ssh doesn't allow the traffic.  I have a later rule to deny all traffic between their respective vlan networks.  If i set either the mgt computer or client to simply IP-group or network and leave the other at IP-port group then it works fine -traffic gets thru -just not when both are setup for ip-port-group -doesn't matter which one i use for the specific (ip-port-group) or general (ip-group). Not a firewall issue -both firewalls (ufw) are disabled on the clients when testing  Am i missing something? 

 

Related, does it make a difference? -is setting the IP-port group more secure on one end or the other? i.e should the admin computer restrict access by IP-port group or should the client?  Easy enough to control via the individual firewalls, but just trying to understand omada better.

 

 

  0      
  0      
#1
Options
8 Reply
Re:ACL rule question -between my management computer/network and clients
2022-06-22 07:46:58

  @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

  0  
  0  
#2
Options
Re:ACL rule question -between my management computer/network and clients
2022-06-22 12:16:28

  @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. 

  0  
  0  
#3
Options
Re:ACL rule question -between my management computer/network and clients
2022-06-22 16:34:36

  @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

  0  
  0  
#4
Options
Re:ACL rule question -between my management computer/network and clients
2022-06-22 20:39:16

@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.

  2  
  2  
#5
Options
Re:ACL rule question -between my management computer/network and clients
2022-06-22 21:00:50

  @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

  0  
  0  
#6
Options
Re:ACL rule question -between my management computer/network and clients
2022-06-22 21:47:46

@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).

  1  
  1  
#7
Options
Re:ACL rule question -between my management computer/network and clients
2022-06-23 03:26:35

  @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)

 

 

 

 

  0  
  0  
#8
Options
Re:ACL rule question -between my management computer/network and clients
2022-06-23 17:30:36

@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...

  1  
  1  
#9
Options