When defining a redirect under Network/Firewall/PortForwards I specify a source zone and where to redirect this request.
What I want: specifying a destination zone (no matter from which source zone it comes) and where to redirect this request (e.g. redirect a request for 1.2.3.4 to 4.3.2.1).
For example: I want to redirect outgoing ntp traffic to an internal ntp server. I do not want to intercept internal ntp traffic.
Accorting to the fw4 documentation, redirects should be applied in the prerouting chain using DNAT target and require to specify one source zone, i.e. each source zone needs a separate redirect.
Using command-line instructions in the beginning and in the end of the DNS hijacking page should give you a template that you can adjust for the NTP protocol and duplicate for each source zone.
Beside the wan zone I have 9 other firewall zones. Sometimes (for testing purpose) this number increases by 5 to 9. It's everything else but not convenient to have a rule for each source zone.
This is what I want (clear text: everything leaving the router via the wan zone with destination port 123 should be redirected to localhost and port 123):
By the time you know the packet is destined for the wan zone, the routing decision has already been made. I don’t believe you can DNAT/REDIRECT in a postrouting chain.
If your internal systems are calling external ntp servers, then the trend seems to be resolving *.pool.ntp.org. If so, just seize the domain internally by firing up your own dns server and have all the A or AAAA addresses point to your internal server. It's what I've done.
The following definition drops all wan traffic to port 123 (NTP):
config rule
option name 'DROP-WAN-NTP'
option src '*'
option dest 'wan'
option dest_port '123'
option target 'DROP'
I do not understand, why I can drop outgoing ntp traffic (via wan interface), but not redirect this traffic to an internal address + port. Perhaps somebody can explain.
this syntax is used by fw4 which is a wrapper on top of nftables. fw4 provides integration of nftables into opwrt ecosystem, working with ubus etc. therefore it is more and less comparing to nftabels in the same time. you can write rules which are limited by design.
but nothing stops you to use nftables either by adding your preferred rule via nft command, or using fw4 framework which allows to import native nft rules and added to fw4 defined firewall setup.