05-28-2024 06:27 AM - edited 05-28-2024 06:35 AM
I am not an expert in setting up ACLs, but I have a good understanding of the basics. However, I feel like I might be missing something.
I have set up a new VLAN to provide direct internet access while blocking communication to other VLANs and on-premises devices.
The primary issue I am having is I can still ping and access certain IP addresses even though traffic should be denied, for example, on the OUT ACL I have the 10.0.0.0/8 subnet deny anything but I can still ping the following IPs which I'm assuming they are other virtual interfaces: 10.200.16.2, 10.8.1.2, 10.8.1.49. I also have 172.0.0.0/8 set to deny and I can ping some printers and other devices with the following IPs 172.20.0.2, 172.20.1.5, 172.20.210.165, 172.20.100.98.
I even set a deny ip any any at the first sequence of the IN and OUT ACL to test and I can still ping these devices but I can't get to anything else. One other thing I cannot figure out is that it seems like no matter what I add on the IN ACL it doesn't affect traffic, the only entry is an implicit deny, and even if I specifically enter in deny ip 10.30.1.0 0.0.0.255 any or entries for the specific ip addresses I can ping, traffic still passes out of the interface.
switches are C9200L-48P
Here is the VLAN config:
interface Vlan30
description GuestWired
ip address 10.30.1.1 255.255.255.0
ip helper-address 172.20.0.x
ip access-group GuestWired-IN in
ip access-group GuestWired-OUT out
Heres the IN ACL
Extended IP access list GuestWired-IN
999 deny ip any any
Heres the OUT ACL
Extended IP access list GuestWired-OUT
10 deny ip 172.0.0.0 0.255.255.255 any
20 deny ip 10.0.0.0 0.255.255.255 any
30 deny ip 192.0.0.0 0.255.255.255 any
999 permit ip any any
Solved! Go to Solution.
05-29-2024 10:06 AM
How would I go about implementing this in my network setup? The only switch I have running layer 3 is the core stack and that is connected via an aggregate link to a layer 2 stack with other layer 2 stacks connected to that. The vendor devices will be connected to a layer 2 stack then go to the layer 2 core then to the layer 3 switch. I never implemented VRFs but to my knowledge, it would only be able to be used if I used a layer 3 switch to connect the vendor device
05-29-2024 12:41 PM
Hello
The VRF is applied at the L3 subnet so any associated access-ports in that vlan will be segregated, the vendor will reside in this guest vlan to get out say to the internet, however saying that to reach the ISP it will need to go via the global route table(GRT) as such it will again be exposed to the other subnets unless your ISP has a separate break out for guest network , if not so then based on what you have now additionally explained about you network vrf may not be applicable.
So returning to the RACL you need to negate the other vlans from the the guest svi which i see you are trying to do, not forgetting you need allow certain traffic through ( igp/dhcp etc...) and be as specfic as possible.
Example based on you other L3 svis:
ip access-list extended vlan
permit ospf any any
permit udp any host 172.20.0.30 eq bootps
permit udp any host 172.20.0.30 eq bootpc
deny ip any 172.20.0.0 0.0.0.255
deny ip any 10.8.1.0 0.0.0.255
deny ip any 172.21.0.0 0.0.255.255
deny ip any 10.44.0.0 0.0.255.255
deny ip any 10.200.0.0 0.0.3.255
deny ip any 10.200.16.0 0.0.7.255
deny ip any 172.24.0.0 0.0.3.255
deny ip any 172.25.0.0 0.0.3.255
deny ip any 172.26.0.0 0.0.3.255
deny ip any 10.3.1.0 0.0.0.255
deny ip any 10.0.0.0 0.0.0.255
permit ip any any
int vlan 30
ip access-group vlan in
05-30-2024 05:55 AM
I'll have to give that a shot, I can contact my ISP and see if they can update the routes in the router, thanks for all your help!
05-30-2024 12:11 AM
this same as your topology (as we know)
NOW R3 GW is 10.0.0.1 and R4 GW is 20.0.0.1
when I ping from R3 to R4 you see success then after I apply ACL
ip access-extended ICMP
deny icmp host 10.0.0.100 20.0.0.100
the ping failed
and you can see when I do traceroute from R3 to R4 I must see GW as first Hop, if you see other Hop then ACL is not work becuase the routing is done via other L3 interface
MHM
05-30-2024 05:51 AM - edited 05-30-2024 05:54 AM
You are correct, I found the issue. A rogue device acting as a DHCP server/type of relay gave me the wrong default gateway, but I didn't notice it until now. Once I removed that device I got the correct gateway and traffic is routing properly through the ACL. Thanks for all your help!
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