Open JoMC98 opened 6 months ago
What would you expect to happen in the case where you have a default matcher and a matcher for 0.0.0.0/0
? Both will match all requests.
In practice, after validation the default matcher is implemented as a matcher against source ip 0.0.0.0/0
or ::/0
(if IPv6 is enabled). The bug here is that your config should be rejected because the two filter chains have duplicate matchers. Perhaps we should allow this case as a way to handle ipv4 vs ipv6 addresses in filter chain match.
Hi Stephan, thanks for the reply.
True, both matchers match, but as the second one has a filter, even if it is 0.0.0.0/0
, isn't it more specific than the default one which has nothing?
I tell you our scenario:
The default filter chain has JWT Authentication and RBAC Authorization filters applied. In our network, we want certain IP ranges not to have these filters applied, so we create the second filter chain, matched by
sourcePrefixRanges
. In a normal scenario, this works fine.Now, we have proposed to use this use case for a Plan B scenario, where we need all traffic to reach the upstream without applying the JWT and RBAC filters. So, in a simple way in our infrastructure, we can change the range of the
sourcePrefixRanges
and we had thought of changing it to0.0.0.0/0
so that all traffic would go through the second filter chain.
How could we do this taking into account what you said about the 0.0.0.0/0
range?
Title: Filter chain match by
sourcePrefixRanges
is not working correctly with CIDR0.0.0.0/0
Description:
Config that works with
127.0.0.0/24
:Config that NOT works with
0.0.0.0/0
: