Hello,
For a succesful communication between all the hosts in subnet 192.168.153.0/24 to host 172.21.1.72 it is not enough to allow it just in one direction. The return traffic from 172.21.1.72 to all hosts in 192.168.153.0/24 should also be explicitly allowed. This is not a stateful ACL where all the return traffic leoging to a session will also be imlicitly allowed, you have to configure a separete ACL rule.
However this rule will contradict with you other requirement which says that 172.21.1.72 should be able to communicate only to 192.168.153.20. You need to allow return traffic to all hosts in the subnet, like here in rule 15.
ip access-list extended "FDC"
10 permit ip 192.168.153.0 0.0.0.255 172.21.1.72 0.0.0.0
15 permit ip 172.21.1.72 0.0.0.0 192.168.153.0 0.0.0.255
20 deny ip 192.168.153.0 0.0.0.255 172.21.0.0 0.0.255.255
30 deny ip 172.21.0.0 0.0.255.255 192.168.153.0 0.255.255.255
40 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
exit
If you want to allow only tcp traffic from 192.168.153.0/24 to host 172.21.1.72 you can use the keyword "established" for the return traffic. This will mean that return traffic for TCP sessions from host 172.21.1.72 to subnet 192.168.153.0/24 will only be allowed if the session is established and was initiated by the 192.168.153.0/24 subnet.
The same applies to the communication between hosts 172.21.1.72 and 192.168.153.20.
Here is how the 2 rules would look like. All TCP traffic from 192.168.153.0 to host 172.21.1.72 is allowed.
TCP traffic from host 172.21.1.72 is only allowed if the session is established.
10 permit tcp 192.168.153.0 0.0.0.255 172.21.1.72 0.0.0.0
20 permit tcp 172.21.1.72 0.0.0.0 192.168.153.0 0.0.0.255 established
The whole ACL could look like this
10 permit tcp 172.21.1.72 0.0.0.0 192.168.153.20 0.0.0.0
20 permit tcp 192.168.153.0 0.0.0.255 172.21.1.72 0.0.0.0
30 permit tcp 172.21.1.72 0.0.0.0 192.168.153.0 0.0.0.255 established
40 deny ip 172.21.1.72 0.0.0.0 192.168.153.20 0.0.0.0
50 deny ip 192.168.153.20 0.0.0.0 172.21.1.72 0.0.0.0
60 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
Hi @Emil_G, pardon if I chime in (not to hijack this thread) but your statement:
@Emil_G wrote: For a succesful communication between all the hosts in subnet 192.168.153.0/24 to host 172.21.1.72 it is not enough to allow it just in one direction. The return traffic from 172.21.1.72 to all hosts in 192.168.153.0/24 should also be explicitly allowed. This is not a stateful ACL where all the return traffic leoging to a session will also be imlicitly allowed, you have to configure a separete ACL rule.
made me scratching my head.
I have an apparently working extended ACL - called "2102" - applied as incoming (In) on the VLAN 2102 (permitting the whole subnet 10.255.102.0/24 to reach hosts or subnets on other routed VLANs in a similar fashion to what the OP is requiring) and I never needed to apply any matching ACLs on all other involved VLANs (and those are many) to allow (permitted) and/or to block (denied) traffic.
I have something like:
ip access-list extended "2102"
101 remark "Permit VLAN 2102 to node0.1"
101 permit ip 10.255.102.0 0.0.0.255 10.255.0.1 0.0.0.0
102 remark "Permit VLAN 2102 to node0.2"
102 permit ip 10.255.102.0 0.0.0.255 10.255.0.2 0.0.0.0
104 remark "Permit VLAN 2102 to node2.21"
104 permit ip 10.255.102.0 0.0.0.255 10.255.2.21 0.0.0.0
250 remark "Permit VLAN 2102 to RDS Server (Legacy VLAN)"
250 permit ip 10.255.102.0 0.0.0.255 192.168.10.1 0.0.0.0
260 remark "Permit VLAN 2102 to its SVI"
260 permit ip 10.255.102.0 0.0.0.255 10.255.102.254 0.0.0.0
270 remark "Permit VLAN 2102 to itself"
270 permit ip 10.255.102.0 0.0.0.255 0.0.0.0 0.0.0.0
280 remark "Permit VLAN 2102 to Firewall CVI (Legacy VLAN)"
280 permit ip 10.255.102.0 0.0.0.255 192.168.10.250 0.0.0.0
300 remark "Deny VLAN 2102 to VLAN 2100"
300 deny ip 10.255.102.0 0.0.0.255 10.255.100.0 0.0.0.255 log
301 remark "Deny VLAN 2102 to VLAN 2101"
301 deny ip 10.255.102.0 0.0.0.255 10.255.101.0 0.0.0.255 log
400 remark "Deny VLAN 2102 to 10.140/16 VLANs (Campus VLANs)"
400 deny ip 10.255.102.0 0.0.0.255 10.140.0.0 0.0.255.255 log
401 remark "Deny VLAN 2102 to 192.168.10.0/24 (Legacy VLAN)"
401 deny ip 10.255.102.0 0.0.0.255 192.168.10.0 0.0.0.255 log
999 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
exit
Thus having just that ACL means I'm managing the responses to request coming from permitted/denied external (to VLAN 2102) hosts...which doesn't mean that I'm explicitly blocking incoming traffic to VLAN 2102.
The intent was to "protect" all hosts belonging to VLAN 2102 from reaching hosts belonging to other specific subnets (by denying traffic back related to incoming requests from VLAN 2100 and VLAN 2101 subnets or any 10.140/16 subnet, as example) and just permitting traffic back (so outgoing from VLAN 2102, incoming into the router) when the communication is initiated by those external hosts (but it also works when the communication is initiated by internal VLAN 2102 hosts).
Should I worry?
I'm not an HPE Employee
Hello @parnassus,
Of course you can feel free to present your sight and your solution for this issue. Everyone can overlook something or make a mistake and at the end of the day the goal is to help. It is called "community" after all.
I think the difference between the configuration presented in the question and your configuration may be the fact that here we have the same ACL applied inbound to both VLANs which should be controlled. I am not sure what ACLs you have applied to your other VLANs.
Traffic outbound in VLAN 1 will be inbound in VLAN 2 and vice versa. Thats why I thought that return traffic should also be permitted.
@Emil_G wrote: I think the difference between the configuration presented in the question and your configuration may be the fact that here we have the same ACL applied inbound to both VLANs which should be controlled. I am not sure what ACLs you have applied to your other VLANs.Traffic outbound in VLAN 1 will be inbound in VLAN 2 and vice versa. Thats why I thought that return traffic should also be permitted.
Well, in my case there aren't additional ACLs applied to all other involved VLANs. That's the point.
Maybe the main difference is that applying ACLs reciprocially (exactly because "Traffic outbound in VLAN 1 will be inbound in VLAN 2 and vice versa" as you wrote) will filter traffic also bidirectionally (so Host/Subnet on VLAN A is permitted/denied to reach Host/Subnet on VLAN B AND vice-versa)...while applying ACL only on one VLAN (Inbound) will filter only one direction for that very VLAN...the returning direction (which means that traffic from other VLAN can reach the VLAN where the ACL is applied inbound BUT this is the only VLAN where permit/deny rules will effectively permit/deny traffic back to those other VLANs). Does it make sense?
I'm not an HPE Employee
Hello,
Yes, the ping is not TCP traffic. ICMP is a separate IP protocol. If you need connectivity for all IP protocols regardless TCP, UDP, IMCP, GRE or others, I am afraid you need to allow all communication between subnet 192.168.153.0 and host 172.21.1.72 in both directions see my first example.
ip access-list extended "FDC"
10 permit ip 192.168.153.0 0.0.0.255 172.21.1.72 0.0.0.0
20 permit ip 172.21.1.72 0.0.0.0 192.168.153.0 0.0.0.255
30 deny ip 192.168.153.0 0.0.0.255 172.21.0.0 0.0.255.255
40 deny ip 172.21.0.0 0.0.255.255 192.168.153.0 0.255.255.255
50 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
exit
I know it is not flexible enough but I personally cannot think of any other way of doing it. I may be wrong.