IOS-XE HTTP Access-Class with non-contiguous wildcard mask?

[Wilfried Olthoff]

Hi Community,

I would like to use an ACL to limit the access to the HTTP(S) service of some C9300 switches using the "ip http access-class" command.

The goal is to allow many /19 subnets where only the 2nd octet differs with just a single entry in the ACL.

Something like this: 10.*.128.0/19

I tried to use a special non-contiguous wildcard mask to achieve this like in the following example:

ip access-list standard HTTP_ACCESS

 10 permit 10.0.128.0 0.255.31.255

!

ip http access-class ipv4 HTTP_ACCESS

I know, that I could create an ACL with 256 entries having the desired result, but this is something I would like to avoid.

Unfortunately, it seems that the HTTP access-class does not work with this non-contiguous wildcard mask logic.

At least not on the C9300 switches, where I have tested this. IOS-XE version is 17.9.3.

I can apply the ACL, but I don't get the expected result.

It looks like IOS is just looking for the first binary 1 (a.k.a the "don't care bit") in the wildcard mask and internally converts the following bits also into a binary 1.

"permit 10.0.128.0 0.255.31.255" seems to be handled like

"permit 10.0.128.0 0.255.255.255" (which would basically be the same as 10.0.0.0 0.255.255.255)

Does anyone have an advice for me or an alternative approach?

Best Regards,

Wilfried

[Joseph W. Doherty]

Grasping for straws suggestions. . .

Don't recall, but if http access accepts extended ACLs, you might try that.

You might try a regular interface ingress ACL limiting http/https access to device IPs.

[MHM Cisco World]

Yes I am with @Joseph W. Doherty  
try use extended ACL apply it to interfaces.
also what you face exactly here ?

Thanks A Lot
MHM

[MHM Cisco World]

https://learningnetwork.cisco.com/s/question/0D53i00000KsxiuCAB/discontigous-wildcard-acls

months ago I try to understand the best way to config the discontigous wildcard for ACL, and I found simple way, check the link.

Thanks A Lot
MHM

[Richard Burts]

Some observations, but unfortunately no solution. If you use extended acl on interfaces to control the http access there are multiple challenges:

- you must be careful not to impact transit traffic which uses the protocol.

- you must apply it on each interface which might receive the traffic.

- you must deal with the possibility that any interface on the device might be the destination so multiple lines in the acl.

The advantage of access-class is that there is no impact on transit traffic, you apply it once, and you don't need to specify destination address so the acl is more simple.

I wish I had some insight about discontiguous masking. It works with some acl using access-group. access-class is a different process and works quite differently so its treatment of discontiguous mask might be different.

[Joseph W. Doherty]

What @Richard Burts describes - all true.

Concerning:

"you must deal with the possibility that any interface on the device might be the destination so multiple lines in the acl."

Sort of recreates the problem you're trying to avoid, i.e. multiple ACEs.

Concerning:

"I wish I had some insight about discontiguous masking. It works with some acl using access-group. access-class is a different process and works quite differently so its treatment of discontiguous mask might be different."

Both surprising and not surprising.  One would think a uniform methodology would be used for ACEs regardless of where used, but for likely good reasons (or old, but no longer good reasons), Cisco has different methodologies, and possible for other reasons, has decided to not merge to using just one methodology.

[Richard Burts]

Joseph

The more that I think about it the less surprising it is. A acl is a tool and the tool can be used for multiple purposes: It might be used to filter traffic coming into or going out of a layer 3 device, it might be  used to control routing updates, it might be used to control NAT, it might be used to control access to management functions on the device. Each of those functions uses different (and independent) code to achieve different results and it is logical that they might treat the tool in different ways. There has been a recent discussion in the community about access-class and the fact that access-class does not care about the destination address and how that can produce a surprising result when you use the log parameter in the acl.

[Joseph W. Doherty]

"The more that I think about it the less surprising it is."

Rick, laugh, surprise, perhaps like beauty, is in the eye of the beholder.  As my BSc in in software, and having been a software developer for several decades, I might have a slight different view on software components.

What you describe is entirely possible, but from my experience, software that's been in use, with on-going revisions, for decades, internally, can be, ah shall we say, interesting.

As an example, way back early in my career, my employer sent me to a week long "internals" class, for system programmers using IBM 370 systems.  During the course, as we reviewed various control structures that the OS used, some were noted as no longer being used, as having be superseded by newer structures.  So we asked, why are they still present?

The answer was, IBM wasn't sure they successfully migrated all other OS software components from using them, so they left them in place.

Or, at a fairly large bank, they had lost the source code for one of their major subroutines!  Well, how do I get that subroutine into my revised program that uses it?  You use the linkage editor, to pull the module out of the prior program's executable image, and insert it into your revised image. (Well I did learn something new, how to use the linkage editor to edit binary load images.  First and last time ever had to do that, though.)

I tell people, when you get into large scale software, it's not surprising there might be bugs, what's surprising it works at all.  ; )

So, for me, what's surprising is that an ACE mask doesn't work the same across these two functions, as I cannot see a reason why it shouldn't, but it's not surprising because software development can be like making sausage, it's often not a pretty sight.

Let me put in another way, every notice the quantity and/or quality of an Enterprise's network documentation can vary considerably, even when the actual networks are similar and work just as well?  Code "quality", and its supporting documentation, can very much be like that too.

[Richard Burts]

Joseph

I do not disagree with anything that you have said here. In thinking about consistency in how things work I was struck with this: the OP says "It looks like IOS is just looking for the first binary 1 (a.k.a the "don't care bit") in the wildcard mask" which is exactly the behavior of masking used for the IP address. No discontiguous allowed.