RDP ACL
Hi, I have a case related to ACLs.
In my organization, I have configured multiple VLANs with different network addresses. For now, I’m focusing on two of them:
-
Default VLAN:
192.168.10.0/24 -
LocalLabComputer VLAN:
192.168.23.0/24
In the Default VLAN, there is a server managing antivirus software, with the IP address 192.168.10.22 (for example).
Objective:
I want to block all traffic from the LocalLabComputer network to the Default network,
but still allow two-way communication between the antivirus server and the hosts in the LocalLabComputer network.
I have configured 3 ACL rules (in order):
-
Rule 1:
-
Source: IP-Port Group
ST00(the server) -
Destination:
Network: LocalLabComputer -
Permit: TCP, UDP, ICMP, RDP
-
-
Rule 2:
-
Source:
Network: LocalLabComputer -
Destination:
IP-Port Group: ST00 -
Permit: TCP, UDP, ICMP, RDP
-
-
Rule 3 (last one):
-
Source:
Network: LocalLabComputer -
Destination:
Network: Default -
Deny: All protocols
-
Problem:
-
From the
LocalLabComputernetwork, RDP and port 4000 connections to theDefaultVLAN are still working — even though they should be blocked. -
But from the
DefaultVLAN, RDP toLocalLabComputerdoesn't work — even though it should be allowed.
I'm wondering what I might have done wrong. Can someone point out where the mistake could be?
I forgot to add that these are rules made on Switch ACL
There are two aspects for you to be careful about. But let's set the expectation first, ACL is entirely based on what you configure, it works straight as you configured. There is no reports about the GW or SW ACL.
1. When you set this kind of network, you need to make sure you are using 0-65535 as the source initiates the connection to the 3389, in your example, from a random port.
2. And if you bear this in mind, you should configure as I have. Yet, there is a problem with the controller when you use the IP-Port Group.
The switch or the router does not pose a problem at all. It's the controller issue. See the config below, you'll see.
You should set it as follows.
You can ignore the 3 and 4, which are not effective, because 0-65535 is not effective as of now, V5.15.24.18. Will explain this in the end.
* If this bug is fixed in the future, anyone else who reads this can simply use the rules 1, 2, and 3 or 4. Or simply go for the 1, 2, and 5. Rule 3 and 4 are the same. If you have rule 3, rule 4 is not necessary. Vice versa.
See, the port is using a mask instead of 0-65535. The rest of the config, you can keep it like mine or yours. Using the single port for that IP port range is okay.
Instead of using the IP-Port range, use the IP-Port mask. There is a bug in the controller where it cannot properly set the range. As I read the CLI output from the controller, this is clearly wrong when I set 0-65535. Port mask should not be fffc.
The key in this is misconfig. The source port should be 0-65535. And the scheme is basically correct.
There are two aspects for you to be careful about. But let's set the expectation first, ACL is entirely based on what you configure, it works straight as you configured. There is no reports about the GW or SW ACL.
1. When you set this kind of network, you need to make sure you are using 0-65535 as the source initiates the connection to the 3389, in your example, from a random port.
2. And if you bear this in mind, you should configure as I have. Yet, there is a problem with the controller when you use the IP-Port Group.
The switch or the router does not pose a problem at all. It's the controller issue. See the config below, you'll see.
You should set it as follows.
You can ignore the 3 and 4, which are not effective, because 0-65535 is not effective as of now, V5.15.24.18. Will explain this in the end.
* If this bug is fixed in the future, anyone else who reads this can simply use the rules 1, 2, and 3 or 4. Or simply go for the 1, 2, and 5. Rule 3 and 4 are the same. If you have rule 3, rule 4 is not necessary. Vice versa.
See, the port is using a mask instead of 0-65535. The rest of the config, you can keep it like mine or yours. Using the single port for that IP port range is okay.
Instead of using the IP-Port range, use the IP-Port mask. There is a bug in the controller where it cannot properly set the range. As I read the CLI output from the controller, this is clearly wrong when I set 0-65535. Port mask should not be fffc.
The key in this is misconfig. The source port should be 0-65535. And the scheme is basically correct.