Apparently it increases the counter, but in dnsleaktest.as Cloudflare shows. On the router I have NextDNS as upstream DNS. The rule forwards to the same router and not to another device. Still, I see ads on the client when using dns 1.1.1.1.
Edit: Interestingly when using 9.9.9.9 as dns on the client, in dnsleaktest.como it reveals NextDNS on the client. I tried with 8.8.8.8 and the same thing happens as with Cloudflare, but in this case it reveals Google.
Yes, I set it up too. However, one more NAT setting was missing.
Instructions here: DNS Port Forward + NAT harcoded DNS
Question: How can I set source ip for multiple !except ip addresses ?
Nice link. That DNS Leak Test is also a great way to test VPN connections.
As an aside, my WRT32X has a 50+ day uptime from a master snapshot and running rock solid and very fast. Considering the huge amount of packages and services I have running consider this a testament to how stable OpenWrt is, thanks devs... But still pre-nftables, is it worth doing a new build with nftables yet?
I find the current master branch to be very stable in terms of nftables and firewall4, but I don’t use too many additional packages.
I can also confirm that redirecting DNS via port forwarding works. I redirect everything on port 53 to the router (10.0.0.1), which runs unbound for dns resolution. My firewall UCI config for this rule is:
config redirect
option name 'Redirect-DNS'
option target 'DNAT'
option src 'lan'
option src_ip '!10.0.0.1'
option dest_port '53'
option src_dport '53'
list proto 'tcp'
list proto 'udp'
Another way to test it is working (provided you have a windows system with a hard-wired ethernet connection to your local dns resolver) is by using GRC's DNS benchmark.
With the DNS-redirect firewall rule disabled, the DNS benchmark results should look something like:
With the DNS-redirect firewall rule enabled, the DNS benchmark results should look something like:
If the redirect rule is working, when enabled the DNS bench results should all be roughly identical (since your local DNS resolver is se2rving all the DNS record requests) and, assuming your local dns resolver caches DNS records and is hard-wired to the computer running the DNS benchmark, all dns servers should have cached response times of basically 0.
Please consider opening a new topic with this question as it's not directly related to general tips and tricks for the community. You will probably get better visibility and help in a dedicated topic. Thanks!
The new optimization feature in nftables 1.0.2 shows an opportunity to use a verdict map to replace 2 separate rules. Just an idea…
root@router:~# nft -o -c -f rules.nft
Merging:
rules.nft:37:3-31: iifname "eth0" jump input_lan comment "!fw4: Handle lan IPv4/IPv6 input traffic"
rules.nft:38:3-31: iifname "eth1" jump input_wan comment "!fw4: Handle wan IPv4/IPv6 input traffic"
into:
iifname vmap { eth0 : jump input_lan, eth1 : jump input_wan } comment "!fw4: Handle lan IPv4/IPv6 input traffic"
Merging:
rules.nft:45:3-33: iifname "eth0" jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
rules.nft:46:3-33: iifname "eth1" jump forward_wan comment "!fw4: Handle wan IPv4/IPv6 forward traffic"
into:
iifname vmap { eth0 : jump forward_lan, eth1 : jump forward_wan } comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
Merging:
rules.nft:55:3-32: oifname "eth0" jump output_lan comment "!fw4: Handle lan IPv4/IPv6 output traffic"
rules.nft:56:3-32: oifname "eth1" jump output_wan comment "!fw4: Handle wan IPv4/IPv6 output traffic"
into:
oifname vmap { eth0 : jump output_lan, eth1 : jump output_wan } comment "!fw4: Handle lan IPv4/IPv6 output traffic"
The comment gets confused. Apparently both lan and wan rule would state "lan" in comment.
True. I was just posting it as an idea how firewall4 might optimize the ruleset in ucode, versus using the command line switch.
The NFT experiments crashed menuconfig once again:
tmp/.config-package.in:102205:error: recursive dependency detected!
tmp/.config-package.in:102205: symbol PACKAGE_iptables-legacy is selected by PACKAGE_iptables-nft
tmp/.config-package.in:103012: symbol PACKAGE_iptables-nft is selected by PACKAGE_opennds
tmp/.config-package.in:101235: symbol PACKAGE_opennds depends on PACKAGE_iptables-legacy
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
That doesn't crash/prevent the config itself, and is actually due for opennds.
I dont understand how such problems could not be recognized after changing these nft thing. Everybody sees them after a checkout
Well, they have been recognised, but so far the opennds author has not changed the dependencies in his package Makefile since https://github.com/openwrt/routing/pull/821 as he believes that main OpenWrt code should be changed instead. Complex dependencies can be difficult, also when used for negation (CONFLICTS)
Cool, I also had that meaningless runabout dependables error you talk about in the link when I tried to make my first build for my dgs-1210-10mp in master about a week ago.
Got fed up with master and its errors so I build it in 22.03 instead.
22.03 is also showing these errors...
dme300@naspc:~/src/openwrt/22.03-head$ make menuconfig
tmp/.config-package.in:101937:error: recursive dependency detected!
tmp/.config-package.in:101937: symbol PACKAGE_iptables-legacy is selected by PACKAGE_iptables-nft
tmp/.config-package.in:102744: symbol PACKAGE_iptables-nft is selected by PACKAGE_opennds
tmp/.config-package.in:100967: symbol PACKAGE_opennds depends on PACKAGE_iptables-legacy
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.
For me it was then only for master, has the problem been backported to 22.03?
I think so. I noticed this issue on 22.03 over the weekend. On previous builds I did a week ago or so did not have this error.
EDIT 1: strange. I just did a "make distclean / feeds update -a / feeds install -a" and executed "make menuconfig" with the same .config on 22.03 branch and now the error is gone. Since I did not updated my sandbox, I believe that this issue might have been fixed on a package repository for 22.03.
EDIT 2: confirmed. The fix was committed a few hours ago in routing.git (both for 22.03 and master):
master:
https://git.openwrt.org/?p=feed/routing.git;a=commit;h=8574cb411a1437ad09f047c0e683a126d8ccdd95
22.03:
https://git.openwrt.org/?p=feed/routing.git;a=commit;h=e64a2b4b29a92a000ee6aaf448af8b594dd79155
For fw3/iptables, I have this in my firewall.user to fix a problem with Verizon FIOS doing something odd with TTLs that interferes with traceroute from some clients.
iptables -t mangle -A POSTROUTING -o eth0 -m ttl --ttl-eq 1 -j TTL --ttl-set 2
and I came up with substitute for fw4/nftables, to be put into /etc/nftables.d/01-mangle-ttl-fios.nft:
chain mangle_postrouting_fios {
type filter hook postrouting priority 100; policy accept;
oifname $wan_devices counter ip ttl 1 ip ttl set 2 comment "!fw4: bump TTL for FIOS"
}
Should I use something else for the priority?
No, the priority is fine
Also worth noting that the location of the counter keyword is significant. If you only want to count packets leaving with a ttl of 1, counter should be moved AFTER ip ttl 1. Otherwise it’s counting all packets leaving on $wan_devices.
oifname $wan_devices ip ttl 1 counter ip ttl set 2 comment "!fw4: bump TTL for FIOS"