cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4525
Views
2
Helpful
34
Replies

ACL Issues with denying traffic

db3772
Level 1
Level 1

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

 

 

 

34 Replies 34

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

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

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

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!

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

Screenshot (505).pngScreenshot (506).png

Screenshot (507).png

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!