4

I have written ACL rules written for a Dell PowerConnect 8024F (which, for the most part, uses the Cisco ACL "language") to isolate WiFi traffic from the rest of the network but allow the traffic on VLANs to access internet traffic.

That is to say, the ACL rules allow traffic from a VLAN carrying WIFI traffic to a Transit VLAN whose other endpoint is a firewall interface, but disallows any ingress/egress traffic from that VLAN (i.e. I am trying to forbid "cross-talk" between wireless and wired traffic, if that makes sense).

What I have so far works, but the future problem I am observing is that the current rules I have are ending in "permit all" rule instead of "deny all" rule - and are thus scaling poorly, as I have to amend a bunch of ACL for each new VLAN that I am adding. The added workload is not so much the problem - it's the fragility/forgetfulness of the mind; it feels...wrong to have to do this and I am almost sure there is better way. Unfortunately, I have not found a better way and would definitely like to do that.

Just to make it a slightly less informal - assume four VLANs:

- A and B => wired VLAN traffic    (VLAN 10/20 - IP range 10.0.10.0/24 and 10.0.20.0/24)
- W       => wireless VLAN traffic (VLAN 240   - IP range 10.0.240.0/24)
- T       => transit VLAN traffic  (VLAN 300   - IP range 172.16.0.0/29)

I'd like write a set of rules such that traffic:

- A <-> W => denied
- A <-> T => permitted
- B <-> W => denied
- B <-> T => permitted
- W <-> T => permitted

( <-> meaning traffic flowing both ways)

Rules I've initially written were written like so:

  • A) access-list secure_wifi permit ip 10.0.240.0 0.0.0.255 172.16.0.0 0.0.0.7 (meaning: "allow wireless traffic to transit vlan")
  • B) access-list secure_wifi permit ip 172.16.0.0 0.0.0.7 10.0.240.0 0.0.0.255 (meaning: "allow transit vlan traffic to wireless vlan")
  • C) access-list secure_wifi permit ip 0.0.0.0 127.255.255.255 172.16.0.0 0.0.0.7 (meaning: "allow traffic to WAN traversing transit vlan")

This is all I think I should have but applying these gives me tracert timeout after the VLAN and no internet traffic. I've tried many different combinations of these rules as both inbound and outbound rules (and mixes between the two) but I never really got it to work properly. The best I have done was to make tracert hop to transit VLAN and then mysteriously timeout. I have also found myself confused with "what traffic is inbound or outbound to a given port?".

Instead, what I ended up doing is something like this (these are bound as port inbound ACL):

access-list secure_wifi deny ip 10.0.10.0 0.0.0.255 10.0.240.0 0.0.0.255
access-list secure_wifi deny ip 10.0.240.0 0.0.0.255 10.0.10.0 0.0.0.255
access-list secure_wifi deny ip 10.0.15.0 0.0.0.255 10.0.240.0 0.0.0.255
access-list secure_wifi deny ip 10.0.240.0 0.0.0.255 10.0.15.0 0.0.0.255
access-list secure_wifi deny ip 10.0.20.0 0.0.0.255 10.0.240.0 0.0.0.255
access-list secure_wifi deny ip 10.0.240.0 0.0.0.255 10.0.20.0 0.0.0.255
access-list secure_wifi deny ip 10.0.30.0 0.0.0.255 10.0.240.0 0.0.0.255
access-list secure_wifi deny ip 10.0.240.0 0.0.0.255 10.0.30.0 0.0.0.255
access-list secure_wifi permit any any

What piece of knowledge am I lacking? How can I write these rules more simply and maintainably?

EDIT: fixed a typo and added a "C)" rule that I had tried, somewhat in desperation.

0
5

Since you want to permit WAN traffic, matching only any, you need to have a permit any any at the end.

Basically, you want to deny traffic in and out of the Wi-Fi VLAN. For each of the other VLANs you need a

deny ip 10.0.240.0 0.0.0.255 <otherSubnet> <subnetWildcard>

on the incoming interface or the VLAN of the wireless subnet and

deny ip <otherSubnet> <subnetWildcard> 10.0.240.0 0.0.0.255

on the incoming interfaces or VLANs of the non-wireless subnets - which is basically what you have.

Depending on your overall logic, you could also simply apply

 deny ip 10.0.240.0 0.0.0.255 10.0.0.0 0.255.255.255
 deny ip 10.0.0.0 0.255.255.255 10.0.240.0 0.0.0.255

to deny all local traffic for Wi-Fi nodes in and out of any present and future 10.0.0.0/8 subnet. If there are more private subnets from the other RFC 1918 ranges, just add

 deny ip 10.0.240.0 0.0.0.255 172.16.0.0 0.15.255.255
 deny ip 172.16.0.0 0.15.255.255 10.0.240.0 0.0.0.255
 deny ip 10.0.240.0 0.0.0.255 192.168.0.0 0.0.255.255
 deny ip 192.168.0.0 0.0.255.255 10.0.240.0 0.0.0.255

before permit any any. If you require exemptions to those general denies, add more specific permit lines above the first deny (since ACL entries are applied on a first-hit basis).

Regarding your 'transit VLAN' edits: transit networks are irrelevant for ACLs. Basic ACLs filter by packet source IP and destination IP only. Unless you want the (otherwise denied) wireless client to talk to a node within the transit VLAN, there's no need for that rule.

4
  • Thanks - this is very useful. I've fixed the permit any any typo added a C) case of what I've tried (which is a bit of Hail Mary but still worthy of trying). Yes, that is exactly what I am trying - you are saying the way I have it right now is the only way? I'll try your blanket rules - but won't they prevent interVLAN routing as well? NB, the C) case I had tried would be surprise me if it had worked as, AFAIU, swtich should not even care about. I am trying to understand why these permit rules as I wanted them would not work? I struggled mostly with how to express "WAN traffic" within ACL.
    – quantum
    Sep 1 '21 at 16:52
  • The permit ip 0.0.0.0 127.255.255.255 bit doesn't make too much sense. If you'd like to include all private addresses in the above rules, add deny 10.0.240.0 0.0.0.255 172.16.0.0 0.15.255.255, deny 10.0.240.0 0.0.0.255 192.168.0.0 0.0.255.255 and their reverse directions. No need to explicitly permit anything else if there's a permit any any at the end. won't they prevent interVLAN routing as well? No, just wireless-to-any-other-private-subnet and reverse.
    – Zac67
    Sep 1 '21 at 17:18
  • Agreed - what that permit ip 0.0.0.0 127.255.255.255 intended was to preclude the chance that switch ACL might lock on to traffic whose destination is WAN.....but after leaving the transit VLAN endpoint, switch really shouldn't care - at least not to me.
    – quantum
    Sep 1 '21 at 17:22
  • I am just trying to make the ACLs as easy as possible to maintain. If I add 20 VLANs, ideally I'd like to not have to touch the ACLs that prevent in/out WIFI traffic from leaking out anywhere. Let me give this a shot with the blanket rule and see how that feels.
    – quantum
    Sep 1 '21 at 17:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.