On 06/02/2020 07:29, kfm@xxxxxxxxxxxxx wrote:
On 06/02/2020 02:01, ѽ҉ᶬḳ℠ wrote:
The "redirect" statement results in the packet being directed to the
primary address of the interface on which it was received. That's
non-negotiable. As such, "ip daddr" is not supported as an aspect of
its grammar. Indeed, that's not even how it works for the "dnat"
statement.
For instance, these are valid:
redirect
redirect to :8080
This is invalid:
redirect to 1.2.3.4:8080
Suppose that can/should be inferred from the WIKI
"Is a special case of DNAT where the destination is the current machine."
However, these are valid:
dnat to 1.2.3.4
dnat to 1.2.3.4:8080
Once you address this, any remaining errors should begin to make more
sense.
Right, no error being printed with:
table ip nat { # handle 7
chain input { # handle 1
type nat hook input priority 100; policy accept;
}
chain output { # handle 2
type nat hook output priority -100; policy accept;
}
chain prerouting { # handle 3
type nat hook prerouting priority -100; policy accept;
iif "br-lan" udp dport 53 dnat to 192.168.112.12 # handle 5
iif "br-lan" tcp dport 53 dnat to 192.168.112.12 # handle 6
}
chain postrouting { # handle 4
type nat hook postrouting priority 100; policy accept;
oif "pppoe-wan" masquerade # handle 7
}
}
Yet when packet dumping on the downstream client the capture shows no
sign of the rule taking effect but instead the client communicating
(egress and ingress) unabated with the DNS server set by the client.
Since this being pre-routing tracing/logging seems not applicable in
order to figure out what is (not) happening.
Strangely these iptables rules does not have any effect either
-A zone_lan_prerouting -p tcp -m tcp --dport 53 -m comment --comment
"DNS client hijack prevention" -j DNAT --to-destination 192.168.112.12:53
-A zone_lan_prerouting -p udp -m udp --dport 53 -m comment --comment
"DNS client hijack prevention" -j DNAT --to-destination 192.168.112.12:53
N.B. nft is not deployed when ipt is running and conversely ipt chains
been flushed/removed and ipt kmods been unloaded prior activating nft.
Alternatively, this
table nat {
chain prerouting { oif br-lan ip daddr != 192.168.112.12 udp
dport 53 ip daddr set 192.168.112.12; }
}
As I understand it, "ip daddr set" is permitted but is effectively a
form of stateless DNAT. So, unlike "dnat", the conntrack subsystem
won't automatically handle the rewriting of the source address along
the inverse path. If in any doubt, that's probably not what you want.
Picked the idea up from the man pages [1] but there it is mentioned in a
different context/table (route some packets instead of bridging) and
thought to give a swirl.
[1] https://www.netfilter.org/projects/nftables/manpage.html
