01-24-2024 01:05 PM
Hello, I am attempting to determine a manor of allowing an User VLAN (In this example being VLAN 3) to reach anything on the printer VLAN (In this example being VLAN 4) and allow printer VLAN 4 to respond back. But if printer VLAN 4 attempts reach out on its own will be denied. Is there an ACL / VLAN access map configuration to allow for something like this?
I have attempted to set just an inbound ACL applied directly to the VLAN interface with the VLAN subnets that should be allowed to start connections to User VLAN 3 (alternative version being the VLAN subnets that should be denied) but both result in the same way of the User VLAN can reach out but when it attempts to get a response from a device on printer VLAN 4 fails.
01-24-2024 01:08 PM
But if printer VLAN 4 attempts reach out on its own will be denied.
Can you more elaborate about this point
Thanks
MHM
01-24-2024 01:23 PM
Hello these ACL variations I have applied but result in the same problem of the response from printer 4 VLAN being denied
ACL - ip access-list extended TestACLFilter
ACL variation 1
permit ip 10.2.3.0 0.0.0.255 10.2.5.0 0.0.0.255 (Allowing VLAN 5 to access VLAN 3)
permit ip any any (Without this line the VLAN cannot reach out to the internet because of the deny ip any any rule at the end of every ACL)
ACL variation 2 (A bit backwards for a normal ACL but wanted to see if it made any difference)
deny ip 10.2.3.0 0.0.0.255 10.2.4.0 0.0.0.255 (Blocking printer VLAN 4 from going inbound)
permit ip any any (To allow the VLAN to reach out to the internet and allow any other VLAN internally to reach it)
interface Vlan3
ip access-group TestACLFilter in
01-24-2024 01:43 PM
if the printer use TCP then
you need ACL apply to host VLAN SVI IN
ip access-list extended 100
permit tcp <host subnet> <printer subnet> establish
deny ip <host subnet> <printer subnet>
permit ip any any
this not optimal solution but in end we have ACL not statful FW
MHM
01-25-2024 10:27 AM
Hello MHM, thanks for the suggestion but when it comes to that ACL you suggested it still stops the user vlan from communicating to the printer vlan.
01-25-2024 10:59 AM
Where you apply this ACL?
Add log to end of each line and check
Note:- show access-list to make sure you add each line in order' order here important
MHM
01-25-2024 01:19 PM
I applied it directly to the user VLAN interface set to inbound and I added an additional line as well but yet even though the ping line is before the deny line even pings are still getting denied.
permit tcp 10.1.3.0 0.0.0.255 10.1.4.0 0.0.0.255 establish
permit icmp 10.1.3.0 0.0.0.255 10.1.4.0 0.0.0.255
deny ip 10.1.3.0 0.0.0.255 10.1.4.0 0.0.0.255 log-input
permit ip any any
01-25-2024 01:27 PM
Are you apply any ACL in printer vlan?
MHM
01-25-2024 01:34 PM
I have an ACL applied to the printer VLAN just to see if it matches but nothing beyond that
permit ip 10.1.3.0 0.0.0.255 any
permit ip any any
01-25-2024 01:44 PM
so the host is 10.1.3.0 and printer is 10.1.4.0?
if NOT
swap the IP in acl
MHM
01-29-2024 11:43 AM
The user vlan subnet is 10.1.3.0/24 that is being allowed outbound on the printer vlan which is 10.1.4.0/24
01-24-2024 01:27 PM
Hello @OSUOPT ,
if your traffic is TCP, then you can construct an access list that will permit traffic from vlan 4 to vlan 3 if the packet is not the first packet in a TCP conversation. This is done by adding the established keyword to the access list entries permitting traffic:
access-list 199 permit tcp host <printer IP address> <vlan 3 subnet> <vlan 3 mask> established
This way, if printers in vlan 4 try to establish TCP connections to other host (TCP segment contains only SYN), traffic will be denied. If the printer is just responding to a TCP connection (TCP segment contains SYN ACK or only ACK) traffic will be permitted.
For UDP traffic, unfortunately we don't have the same mechanism.
Hope it helps.
01-25-2024 10:28 AM
Hello, thanks for your suggestion but like MHM cisco world also suggested. When just having that ACL line without a deny line afterward it still allows the printer vlan to start connections instead of just responding to them.
01-24-2024 03:00 PM - edited 01-24-2024 04:07 PM
If device supports, a possible option: Reflexive Access Lists.
Also, if supported, NAT is a possible approach.
Both prior suggestions are stateful.
As the others have already noted, TCP established (also mentioned in the above reference) might be used for TCP conservations.
01-25-2024 08:12 AM
Hello, unfortunately I just went through and attempted to make a Reflexive access list but I can confirm my 4500x is not a supported platform for those. That would be a very good option if that was supported on my device.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide