Why does DNSFilter use the mangle table for IPv6?

[dave14305]

It looks like it's been this way forever, but why does DNSFilter use the mangle table to drop IPv6 traffic? Generally, the mangle table is only for mangling packet headers, not dropping them. Seems this would be better suited for the filter table.

Probably a moot point with newer routers properly supporting the IPv6 DNAT method, but as I was reviewing the DNAT problem from 386.7 and the subsequent reversion to the old method for some routers, it struck me as odd that I was seeing DNSFilter in the mangle table along with my FlexQoS rules.

 

[SomeWhereOverTheRainBow]

It looks like it's been this way forever, but why does DNSFilter use the mangle table to drop IPv6 traffic? Generally, the mangle table is only for mangling packet headers, not dropping them. Seems this would be better suited for the filter table.

Probably a moot point with newer routers properly supporting the IPv6 DNAT method, but as I was reviewing the DNAT problem from 386.7 and the subsequent reversion to the old method for some routers, it struck me as odd that I was seeing DNSFilter in the mangle table along with my FlexQoS rules.

I have had this same preponderance as well. When observing ipv6 DNS traffic on my network, I can see how many hardcoded clients actually use ipv6 for DNS lookups. It would be easier to just drop the packets than trying to DNAT them simply because there are not alot of clients with hardcoded DNS preferring to use ipv6 for lookups. Maybe the mangle tables are being used to exclusively allow ipv6 DNS that matches packets destined for the local network such as the routers ipv6 DNS address.

 

[RMerlin]

It looks like it's been this way forever, but why does DNSFilter use the mangle table to drop IPv6 traffic? Generally, the mangle table is only for mangling packet headers, not dropping them. Seems this would be better suited for the filter table.

There was a reason at the time, but I cannot remember what it was.

It would be easier to just drop the packets than trying to DNAT

Why? DNAT means it will keep working transparently for the user, just like with IPv4, while dropping may potentially completely prevent any name resolution from working with the client. This was a step forward when I backported IPv6 DNAT support.

 

[SomeWhereOverTheRainBow]

Why? DNAT means it will keep working transparently for the user, just like with IPv4, while dropping may potentially completely prevent any name resolution from working with the client. This was a step forward when I backported IPv6 DNAT support.

@RMerlin I have no issue with using DNAT for transparently handling the issue provided there are no hiccups. I think you did a great job with your backport support. Especially with the limited tools and level of complications you may have faced. My statement was merely to also suggest I too wonder about the use of the mangle table as in- what were the intentions?. I feel it probably was to allow clients to still use the router himself for ipv6 DNS traffic instead of exclusively dropping all ipv6 dns traffic instead of the contrary

while dropping may potentially completely prevent any name resolution from working with the client

 

[dave14305]

Maybe the mangle tables are being used to exclusively allow ipv6 DNS that matches packets destined for the local network such as the routers ipv6 DNS address.

This doesn’t make any sense to me.

There was a reason at the time, but I cannot remember what it was.

Did you have IPv6 back then? I can’t think of a valid reason today. I still want to revisit potential kernel backports to fix the DNAT csum issues.

 

[SomeWhereOverTheRainBow]

This doesn’t make any sense to me.

Well it is the only thing that would make sense if you were trying to prevent breaking of dns resolution rather than just dropping it altogether. Maybe specific qualities of the mangle table made it exceptional for this purpose. Your guess is as good as mine though- just conjecture.

Did you have IPv6 back then? I can’t think of a valid reason today. I still want to revisit potential kernel backports to fix the DNAT csum issues.

Anybody in touch with Broadcom or any other potential close source vendors who might need to provide assistance with this?

 

[RMerlin]

Did you have IPv6 back then?

HE tunnel, it wasn`t implemented blindly.

It might be something related to a target not being allowed in the ipv6 nat table, MAC source not being allowed in there, or this being the only location early enough in the iptables flow for it to work as intended, I just can`t remember.

 

[SomeWhereOverTheRainBow]

mangle is for mangling (modifying) packets, while filter is intended to just filter packets.

A consequence of this, is that in LOCAL_OUT, after traversing the tables and getting the filtering decision, mangle may try to redo the routing decision, assuming the filtering decision is not to drop or otherwise take control of the packet, by calling ip_route_me_harder (or in this case ip6_route_me_harder), while filter just returns the filtering decision.

 

[dave14305]

Reference for above reply:

iptables: what the difference between filter and mangle

I am using iptables to to mark the package and want to route based on the marks. First I added the ip rule: sudo ip rule add fwmark 1 prohibit (The "prohibit" is just for test, I will change it...

unix.stackexchange.com

It doesn’t address the dropping issue however.