Re: Error: interval overlaps with previous one (with previously valid configuration)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 1/20/18 1:11 AM, Pablo Neira Ayuso wrote:
On Fri, Jan 19, 2018 at 08:42:52PM -0800, Jeff Kletsky wrote:
With a previously valid configuration, which "includes" files into the main
configuration, I get error messages with the HEAD of master on January 16,
2018 9afd72a883e391e366a1d75bb4e1705357e078e9

systemd[1]: Starting nftables...
apu.allycomm.com nft[31431]: In file included from nftables.conf:396:6-34:
apu.allycomm.com nft[31431]: ./dnat_targets.nft:45:9-23: Error: interval
overlaps with previous one
apu.allycomm.com nft[31431]:         ^^^^^^^^^^^^^^^

Unfortunately, the error message both fails to identify what interval
overlaps as well as failing to identify the location of the conflict.
dnat_targets only has 23 lines. This feels like a similar problem to the
"wrong-file" issues that were previously resolved.

Guessing that the problem was caused by

commit 9a4b513014cfdeaad6d247b72a7924b3a536cfe9
Author: Phil Sutter <phil@xxxxxx>
Date:   Wed Jan 10 21:32:04 2018 +0100

     src: Don't merge adjacent/overlapping ranges

     [...]


I have reverted back to the previous commit

commit 0b3ccd27e12d1df442aa3eac40a2ccb63d6c6407
Author: Phil Sutter <phil@xxxxxx>
Date:   Wed Jan 10 13:43:21 2018 +0100

     build: Restore per object CFLAGS

and at least have an operational system again.


I don't see any commits in today's master branch after the 9a4b51 commit
that seem to relate either to the interval regression, or to the problem
with logging.


How can I trace down this problem?
So we have two bugs here.

1) Could you make an example for us to reproduce the misleading error
reporting? Something that we can simply run here to reproduce the
issue would be great.

2) Is there really any overlap in the set that is defined in
dnat_targets, in those 23 lines, or this error is bogus?

Thanks!
--

Relatively trivial examples to replicate posted at https://bugzilla.netfilter.org/show_bug.cgi?id=1216

Yes, there is overlap, as ::1/128 is a subset of ::/96
That set is declared in blackhole_ipv6.nft with the overlapping elements on lines 13 and 14 of the file.


Related to this symptom, I'm puzzled by the apparent design behavior of prohibiting overlapping ranges at all. By doing so, it seems to prevent or hamper some of the use cases for which not merging ranges has benefit.

For me, I see the benefits of not merging ranges to be two-fold:
* The ranges reported by nft match those in configuration files
* Dynamically modified sets

The first is illustrated in the test case. Clearly seeing that the loopback address is blocked has benefit, even if it is a subset of the mapped-IPv4 block.

In the second case, a firewall that adjusts its rules may want to deal with a sub-range, or even a specific host within an existing sub-range, without having to query the current rule set, and potentially need to unwind merged sets. If a program needs to deal with host A.B.C.D, it should be able to create a set entry for that single host (and later remove it), without needing to know that there is already an entry for A.B.C.0/24. An example of this is a behavior-based firewall, where both the net block and the host have action taken, but that action will be reversed on a different time scale for the host than for the net block.

I don't argue that a "set" should be a "set" in the mathematical sense; each element itself unique. What is limiting is that the relative meaning of the elements of the set ("overlapping interval") impacts their validity. If I have a good reason to have overlapping ranges, I can see no reason to prohibit them. Even performance is an unconvincing argument for me, as it is a conscious decision on my part, for example, to wish to include both ::1/128 and ::/96 and be able to see their presence and manage them independently.

Think about the wide swaths of unallocated IPv6 address space. I'd prefer to deal with them line-by-line, in the same form as the lists are delivered, without having to worry about overlap, merging, or, worse, un-merging.


Jeff

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux