It is not clear to me what I can and cannot do in system scripts via netwatch and yes I have gone to the doc section and its clear as mud as usual.
My intention was to simply use netwatch to run system scripts when a monitored host is up or down.
Within the system script the router is instructed to look for a comment tag and disable or enable the config line associated with the comment tag.
I know netwatch is limited to read/write/reboot/
But what I am doing seems to be changing state enabled to disabled etc…)
Im assuming that is not covered by netwatch nativeley
So looking at the script options, I see policy options all checked checked.
Can I use any of these settings to allow netwatch trigger a system script, OR
is the ONLY option to select dont require permissions box??
Okay I imagine most folks are going to say, DONT USE dont require permissions box its not secure, if so,
Then are you suggesting I simply use NETWATCH to monitor status of host detection and then Write an overarching System Script that calls the two UP and down actions ( scheduled slightly after netwatch cycle). Something like.
# Name of your Netwatch entry
:local nwHost "WGSTATUS"
# Retrieve current status
:local curStatus [/tool netwatch get [find host=$nwHost] status]
# Retrieve previous status
:global netwatchPrevStatus
:if ([:typeof $netwatchPrevStatus] != "str") do={ :set netwatchPrevStatus "" }
# Only act if state has changed
:if ($curStatus != $netwatchPrevStatus) do={
Agree, the policy situation is confusing. But the way to look at netwatch permissions is you can read and write things so… /ip/route set [find comment=] ... is fine. What not fine is changing passwords or adding users, and where the restrictions often come up is /tool/fetch which not allowed from netwatch only recently been allowed.
Just to keep it to together, netwatch doc says this:
Netwatch is limited to read,write,test,reboot script policies. If the owner of the script does not have enough permissions to execute a certain command in the script, then the script will not be executed. If the script has greater policies than read,write,test,reboot - then the script will not be executed as well, make sure your scripts do not exceed the mentioned policies.
With those policies described under User docs:
Config Policies:
reboot - policy that allows rebooting the router.
read - policy that grants read access to the router’s configuration. All console commands that do not alter the router’s configuration are allowed. Doesn’t affect FTP
write - policy that grants write access to the router’s configuration, except for user management. This policy does not allow to read the configuration, so make sure to enable read policy as well
policy - policy that grants user management rights. Should be used together with the write policy. Allows also to see global variables created by other users (requires also ‘test’ policy). Allows to design skins (requires also “sensitive” policy).
test - policy that grants rights to run ping, traceroute, bandwidth-test, wireless scan, snooper, fetch, email and other test commands
sensitive - grants rights to change “hide sensitive” option, if this policy is disabled sensitive information is not displayed.
sniff - policy that grants rights to use packet sniffer tool, torch tool, traffic generator.
You’re not restricted too much for common route changes. So this part isn’t correct:
… so you can look for a comment, and the use enable/disable operations from netwatch.
Fascinating question because I have essentially ignored the security concerns about scripts (that is, many scripts have “DON’T REQUIRE PERMISSIONS” checked), as well as the question about security with a script called within a script (a netwatch script, in this case).
Do BOBBYVPN and AZIREVPN bring down and up, respectively, wireguard connections?
You guys are having WAY too much fun!!
Okay @AMMO, thanks for the serious inject of facts!!
To be clear are you saying that I dont even need system scripts, I can do all from the newatch script
Or are you saying,
I can call the system scripts from the netwatch script without any need to use the checkbox “dismiss all permissions”?
Yup. That’s the main trick with adjusting firewall with netwatch: the ping to “8.8.8.8” (i.e. netwatch test address) has to always work (or not work and not failover) for the WAN path your testing. So you seem to have a route table that does that .
Since Im not sure how Bobby and Azire are setup, I cannot speak to if the scripts themselves do the right thing, but you know how that part works.
Using a :foreach is smart since it covers all possible find results (i.e. 0, 1, or >1) in one line.
Only as a side note/question/doubt:
years ago I had issues (not on Mikrotik devices) with Android phones using 8.8.8.8 “hardcoded” as DNS if the DHCP provided DNS was not responding and that sometimes (rarely) created issues.
Since then I got the habit of NEVER using 8.8.8.8 as canary/check for connection failover, just to exclude this as possible cause of hiccups.
The examples always use DNS as the test host, because it’s simple. But it comes with the risk that test host does not “failover” —since it cannot — as you need something to detect failure on a single WAN.
Once you start routing it only out one WAN… It does mean that DNS traffic to 8.8.8.8 will also fail when the test fails. Both the test ping & DNS all use same route. This is not be a problem as along there are multiple DNS servers are configured (*presuming apps use the system resolver, not all may, some browsers may directly their own DNS).
But I’d recommend using a DNS provider you’re NOT using for DNS as the test host in netwatch. e.g. 1.1.1.1 as the test if you’re using 8.8.8.8/8.8.4.4… as DNS, or use 8.8.8.8 as test if you’re using 1.1.1.1/1.1 as DNS.
I was trying to validate your point about Google DNS. It’s the only public DNS provider that also make a browser and OS that could override normal DNS resolver behaviors without much effort.
But 8.8.8.8 has become a meme of a test host for multiwan. I just followed it even though I agree with @jaclaz on it’s use.
Yep ,
each and every post/example for either recursive or netwatch uses regularly 8.8.8.8, only a very few with a note like “the address you use might not properly work as DNS” or “you shouldn’t set the same address as DNS server”.
.
:
,