iRule URI Matching Not Working as expected.

Forums Technical Forums
, , , ,
1

We have a virtual server that has these three requirements:

  1. mTLS negotiation
  2. Match start of URI
  3. Match CN of certificate

Note: The the virtual server where this iRule is applied does not have a pool configured as I learned that the ‘reject’ command doesn’t necessarily do what I thought it did.

Testing has proven mTLS works and I think the CN validation does too.  The problem is with URI matching.  Using Postman, we’ve found that using a bogus URI fails indefinately until a valid URI is accessed by the same source.  After that, the bogus URI works too.  We just found this so haven’t done extensive testing.

Below is a simplified version of the iRule and this is the sequence of events:

https://virtualserver/bogus - fails

https://virtualserver/uri-a-yaddi-yaddi - works

https://virtualserver/bogus - This works for I don’t know why!!!

Note: Not sure the bogus URI has to be used first but that’s what the tester reported.

when CLIENTSSL_CLIENTCERT {
		set subject_dn [X509::subject [SSL::cert 0]]
		if { $subject_dn != "" }{
		}
}

when HTTP_REQUEST {
		if { [HTTP::uri] starts_with "/uri-a" } {
				if { $subject_dn contains "mauth-a" } {
						pool serverpool-a-443
				} else {
						reject
				}
		} elseif { [HTTP::uri] starts_with "/uri-b" } {
				if { $subject_dn contains "mauth-b" } {
						pool serverpool-b-443
				} else {
						reject
				}
		}
}

The bogus URL does get rejected by the server but it should not have made it there to begin with.  I’m no expert on iRules so I thought I’d post this before searching for a solution.  If you happen to know what the problem is I’d be happy to save the time.

Also, I’m guessing there may be a better way to do this iRule but it was created by a consultant and thought to be working properly until today.

Thanks!

2

you should use “ne” for the subject_dn comparison.
“!=” is for numeric

3

It seems like you’re having trouble with an iRule, that’s supposed to handle mutual TLS (mTLS) negotiation, URI matching, and certificate validation based on the Common Name (CN). The problem you’re encountering is that sometimes a bogus URI gets through even after it should have been rejected. This might be due to caching or session persistence issues.

Try this

when CLIENTSSL_CLIENTCERT {
    set subject_dn [X509::subject [SSL::cert 0]]
    log local0. “CLIENTSSL_CLIENTCERT: subject_dn=$subject_dn”
}

when HTTP_REQUEST {
    log local0. “HTTP_REQUEST: uri=[HTTP::uri] subject_dn=$subject_dn”
    if { [HTTP::uri] starts_with “/uri-a” } {
        if { $subject_dn contains “mauth-a” } {
            log local0. “Matched /uri-a and mauth-a”
            pool serverpool-a-443
        } else {
            log local0. “Matched /uri-a but did not match mauth-a”
            reject
        }
    } elseif { [HTTP::uri] starts_with “/uri-b” } {
        if { $subject_dn contains “mauth-b” } {
            log local0. “Matched /uri-b and mauth-b”
            pool serverpool-b-443
        } else {
            log local0. “Matched /uri-b but did not match mauth-b”
            reject
        }
    } else {
        log local0. “No URI match found, rejecting”
        reject
    }
}

4

You are correct that the statement should have been “ne” however a closer look at that statement proves it doesn’t do anything in the iRule.  It may have been a remnant from a previous version.  Thanks!

5

The final ‘reject’ statement seems to have solved the problem.  Thanks for your help!