The rules must be adapted on need, so i do not specify in-interface-list=LAN or others parameters...
But what happen if also PiHole is down???
Must be used also this...
Set 1.1.1.1 on-down on netwatch AdGuard rule if PiHole is down... So if both are down, 1.1.1.1 is used...
Can be added X DNS server, each with own netwatch... etc.... etc... etc...
/tool netwatch
add disabled=no \
name=test_pihole \
interval=10s \
type=dns \
dns-server=10.10.10.5 \
record-type=A \
host=www.example.com \
timeout=1s \
up-script="\r\
\n/tool netwatch\r\
\n set test_adguard down-script=\"/ip dns set servers=10.10.10.5\"\r\
\n reset test_adguard" \
down-script="\r\
\n/tool netwatch\r\
\n set test_adguard down-script=\"/ip dns set servers=1.1.1.1\"\r\
\n reset test_adguard"
nice touch, I will have to see if the requirement is no internet if both are down LOL.
But on your example how does the server ever get to pi hole, it looks like it goes from adguard to 1.1.1.1
Oh is this a second rule?? where is the primary, the adguard server ??
Yes but its still not clear to me the second rule.
We already have the first netwatch setting the primary and if its down setting the secondary.
I dont get the second netwatch rule becuase it will interfere with the first one. One cannot have two rules competing with one another, it would only make sense to me if the first rule ON THE DOWN interface THEN called a second rule like a nested response.
So if primary is NOT available use other netwatch rule, which then checks if secondary is up and if not up then on down use 1.1.1.1
i am missing something in process or logic or both.
++++++++++++++++++++
PS If you like Danish actors/films, we really liked this one!!! ( dark comedy )
Ahh okay, now I understand the green greek text LOL.
The UP script, on the second rule, doesn't change anything, it merely sets the backup server to what it is already in the first rule. The meat is in the down script which changes the backup server to 1.1.1.1 in the first netwatch setting.
So its nested and nice job!
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Now that we can put that away and get to dessert, why is this script not running on the router.....
We state run script and nothing happens.
to recap
we have these dstnat rules. dst-port=53 in-interface-list=LAN src-address-list=!excluded to-address=10.20.30.30 dst-address-list=Ad-UP
dst-port=53 in-interface-list=LAN src-address-list=!excluded to-address=10.10.10.5 dst-address-list=Pi-UP
When I run the scripts, to test them, I expect to see a firewall address-list entry appear on the router for at least 5 seconds....... ??? However, we see zilcho. Nevermind if we could use netwatch to execute them.
/ip firewall adddress list
name=Ad-UP address=0.0.0.0/0
name=Pi-UP address=0.0.0.0/0
Have you ever seen me use do={ } alone (or useless { } )in any script from 2007 to today?
It makes absolutely no sense and is completely useless. do={ } (not alone) is used for other things....
Why do you have to use { } or do={ } (alone) to simply insert an IP into a list?
dst-address-list=<EMPTY LIST>
or dst-address-list=0.0.0.0/0
blah, blah, blah, etc.
In short, why bother when there's a simpler, less complex solution?
You seem like one of those users who doesn't see the bigger picture, but is obsessed with just one small piece of the problem,
because they want to solve only that, and only the way they thought of it,
without considering an existing, simpler solution that gets straight to the point...
Thats very accurate............. it stems from a lack of confidence, due to inadequate knowledge and even less training.
However, how do you explain the script works with just { } ???
I dont catalog your scripts or commit them to memory, now if they were picasso paintings........
I will admit your solution is less complex, no need for scripts and makes use of DNS service on router, so no deviations from normal, other than a slick dst nat rule/firewall address list combo combined with netwatch.
By the way, I reckon its way past your bedtime LOL
As I always pointed out to another user who's been missing from the forum for a while,
obsessed with SMS (if you remember),
I don't play "what if" games.
Simply using the parentheses { } or the do={} in the /ip firewall address-list add [...] timeout=5s command is completely useless,
and I'm not interested in finding out why it doesn't work,
just as I'm not interested in finding out [even though, in this example case, I know]
why putting diesel fuel in a gasoline-powered car doesn't work.
It's just not done that way...
And if you notice, when the commands to be placed in the events down/up are really simple,
I don't create separate scripts to run in the events
(unless they're commands that require special permissions, but that's another story),
but I place the commands directly in the events (as you can see in the two netwatches I posted),
which is both easier to understand what's happening and easier to maintain.
Perhaps everyone is over complicating the problem, a bit.
If DNS provided by DHCP is always pinned through MikroTik DNS (with allow-remote-request=yes and provided by DHCP server), you can allow MikroTik DNS servers sort out the "next hop". With DNS netwatch checking Adguard can resolve DNS FQDN, and updating /ip/dns in on-up, and setting PiHole DNS on-down. Bonus be adding 2nd DNS netwatch for PiHole that do nothing on on-up but on-down could check 1st netwatch was also down, and then fail to using public or ISP DNS services if 1st netwatch was also down
Now if you don't want to use MikroTik DNS, then netwatch DNS changing DNS servers is going to be delayed by the DHCP lease time - so providing only Adguard DNS to all DHCP clients is less ideal. In this case, on-up/on-down script would change DNS /ip/dhcp-server/network to use PiHole, but there be some delay.
Final option be if clients are provided both Adguard and PiHole in their lease, the clients will failover. Now importantly you cannot control which of the two DHCP clients will use, so some DNS request may go to PiHole even if Adguard is up. Which is why using MikroTik DNS (either alone, or with both MikroTik & Adguard provided in lease) may be a better approach.
Is to not use the MikroTik DNS server but still have DHCP / IPv6 RA pointing DNS to the router's IP addresses (for IPv6 preferably to an ULA address, not the link local fe80 address). But then have DSTNAT rules redirecting everything to AGH. Then the script trigged by Netwatch only changes the value of to-addresses/to-address of the rules.
