I'm working with a customer with around 50 locations and they do not want to centrally switch any traffic, including guest. The challenge is that in WLC 7.5, the behavior of how radius-applied ACLs are used was changed. In the WLC, you can manually set the ingress and egress ACLs to whatever you want, but if the ACL is applied by radius, the same ACL gets applied to ingress and egress. For some use cases, this wouldn't necessarily be a problem. However, with the guest use case it is - or so it seems to me. A standard guest ACL (after redirect and successful login) would allow dns and dhcp, block RFC1918 private address space, then permit all external traffic. If that ACL gets applied to both ingress and egress, then the use case breaks (inbound traffic to the guest that is in the RFC1918 address space is blocked as well). You can work around that by permitting the guest subnet above the denies of course, but in a scaled environment that simply won't work. The ACE limitation per ACL would cap you out pretty quick, but the admin overhead to manage all those extra entries wouldn't be good either.
I opened a TAC case hoping I was just not thinking about this clearly, but it appears this is behavior by design. So, I'm posting to see if anyone else has run into this and what they did to work around it somehow. If you have experienced this and happen to have an active case, I do have a feature request bugID - CSCuv93592. Please ask that your case be added to this feature request.
Any thoughts/comments/potential workarounds welcome!
I understand any to RFC1918 won't work.
What if you only deny it if the source is an RFC1918 and the destination is an RFC1918.
So for example all of your guest networks are 172.16.0.0/20 or whatever mask would cover it. The company uses other addresses in the RFC1918 space.
deny source 172.16.0.0/20 dest 192.168.0.0/16
deny source 172.16.0.0/20 dest 10.0.0.0/8
deny source 172.16.0.0/20 dest 172.16.0.0/20
permit any any
Hi Garry, thanks for your reply - it was creative and does work. But, I'm afraid it has the same issue as putting a permit for the guest subnet above the typical three denies for the RFC1918 traffic - scale. If the customer has contiguous ip space for their guest network and that same space is used at every site, then either of the approaches would work. Typically, customers that use local switching may have the same vlan numbers/names in use across sites but the subnets are different. This customer uses something like 10.xx.13.0 for the guest subnet where xx is the site code. If the environment is small enough to have a single subnet for the guest ip space, they may not have invested in ISE - they might be using LWA (Local Web Auth) on the WLC. Of course, that being said, this issue applies to any radius server, not just ISE.
In my situation, this is an enterprise customer with a good number of sites. The administrative burden of managing a guest ACL with approaching 64 entries seems silly for what should be a simple guest ACL. You also have to account for network topology changes - which means this ACL may have to be modified, not to mention that there is no guarantee that each site only has one guest subnet or contiguous space that can be summarized.. Of course, there is also the issue of 64 entries (max for an ACL defined on the WLC) not being enough in some cases. Think large enterprise in the States with many locations around the globe with small 2-3 AP sized offices.
If I misunderstood or am missing something, straighten me out! :)
If corporate subnet is 10.x.x.x.(guest+corp). How about the following:
permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp any dns
permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp dns any
deny 0.0.0.0 0.0.0.0 192.168.0.0 255.255.0.0 any any any
deny 0.0.0.0 0.0.0.0 172.16.0.0 255.240.0.0 any any any
deny 10.0.0.0 255.0.0.0 10.0.0.0 255.0.0.0 any any any
permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 any any any
Traffic is denied local to local in any direction. But allowed internet access.