TAILMON TAILMON v1.0.20 -July 27, 2024- WireGuard-based Tailscale Installer, Configurator and Monitor (THREAD #1 CLOSED)

[jksmurf]

Has anyone noticed this message before in TailMon

# Health check:
# - Linux DNS config not ideal. /etc/resolv.conf overwritten. See https://tailscale.com/s/dns-fight

Literally only noticed it this morning and never seen previously.
I looked at the said /etc/resolv.conf and it contains my Pi-Hole DNS servers (I have two Pi-Holes acting as Primary / Secondary DNS) and I use DNS Director to force all DNS traffic to them.

Does anyone know what /etc/resolv.conf on the Router had previously or even existed?
Things still working normally, just wondering more than anything

Yup .. in testing and since. Can ignore.

Not sure if this from Tailscale website is related. Also this explanation.

 

[evo17paul]

Thanks as ever @jksmurf .... and I switched to Kernel mode yesterday after conversations

 

[jksmurf]

Thanks as ever @jksmurf .... and I switched to Kernel mode yesterday after conversations

Don’t thank me, this is all @Viktor Jaep and @ColinTaylor. If you knew how little I really know about this stuff you’d be laughing your socks off .

I’m just helping out fielding some questions, because I was such a pest that Viktor agreed to create Tailmon in the first place, just to make me stop begging.

But I’m really, really pleased to see it working out for you and other folks, because I think it’s just a really neat way of networking, for what I want to do at least.

 

[XIII]

# - Linux DNS config not ideal. /etc/resolv.conf overwritten. See https://tailscale.com/s/dns-fight

See my post with a possible workaround.

 

[jksmurf]

possible workaround.

I’d say it was a more probable than possible workaround, great pickup, thanks!

“…and don't want Tailscale to overwrite /etc/resolv.conf, you can either disable MagicDNS for all devices on your tailnet or run tailscale set --accept-dns=false to disable MagicDNS on a single device.”

 

[Viktor Jaep]

Alrighty then; hopefully @Viktor Jaep has enough to go on there and I am sure when he wakes up bright-eyed and bushy-tailed it'll be fixed in a jiffy. All good.

EDIT: Also happens if I change from Kernel to Custom Mode and vv.

So I just had a chance to play with this on my test router...

1.) My test AC-AX88U is in userspace mode
2.) Ran the tailscale update from within TAILMON, updated successfully
3.) On the tailscale start, it complained with the error about wanting to see "--stateful-filtering" on the commandline... but it started.
4.) The router dropped off the tailnet, and came back up by itself
5.) looking at TAILMON, all services were started/running... verified that with commands "tailscale status" and "/opt/etc/init.d/S06tailscaled check"

I haven't stopped/restarted the service again... but I'm guessing it's going to complain about this needed command. Am I right?

What are the effects of using this "--stateful-filtering" command on versions < 1.66.4? Any ideas?

 

[Viktor Jaep]

@Viktor Jaep see the StepE attachment; some weird double (y) questions and an error (from 1.66.4 maybe?) plus as above, tailscale went down OK, but did not come up again, until I did a CLI tailscale up?

Not understanding the issue you were mentioning with this "weird double (y) questions? Could you please elaborate?

 

[jksmurf]

Not understanding the issue you were mentioning with this "weird double (y) questions? Could you please elaborate?

Apologies @Viktor Jaep, on Step E it was actually two different questions in the same sequence, I just misread it.

I thought I’d seen it ask the same question twice but it was probably an early morning “enter” press without a “y/n” and it just asked me “y/n” again.

Sorry can’t help you with the 1.66.4 message, no idea on that. The fact that they say “Stateful filtering is now off by default” in the change log almost suggests such a switch is not needed, so I’m not sure why it’s complaining about it; maybe you could try a —reset and see if it then accepts the install without the error?

[EDIT] Seems like someone on Reddit still had to turn stateful-filtering off manually even after 1.66.4; and there were a few squeals by folks on GitHub regarding stateful-filtering breaking things following 1.66.x having it on by default, then 1.66.4 turns it off by default, ostensibly (but according to the Reddit post, doesn’t?)

Wonder if the non-starting service (and it’s repeatable for me, just tried it again), is due to me being in Kernel mode. I can still only make it start with a tailscale up from the CLI, it doesn’t respond to any number of “U” presses from within Tailmon and it doesn’t restart by itself.

 

[Viktor Jaep]

So I have it working... it took a little bit of manual manipulation, but this is what I did (in userspace mode):

1.) In TAILMON, s(T)op the services/connection, close out of TAILMON completely/stop the script
2.) From an SSH prompt, execute /opt/etc/init.d/S06tailscaled start
3.) From an SSH prompt, execute tailscale up --reset
4.) From an SSH prompt, execute tailscale down
5.) From an SSH prompt, execute tailscale up --advertise-routes:192.168.50.0/24 (or whatever your local network subnet is)
6.) Open TAILMON back up again... everything is running as normal
7.) Starting/stopping connections works again as normal.

In the end, I think this --reset is what helped clear things out again... Gosh I hope this doesn't happen very often.

 

[jksmurf]

So I have it working... it took a little bit of manual manipulation, but this is what I did (in userspace mode):

1.) In TAILMON, s(T)op the services/connection, close out of TAILMON completely/stop the script
2.) From an SSH prompt, execute /opt/etc/init.d/S06tailscaled start
3.) From an SSH prompt, execute tailscale up --reset
4.) From an SSH prompt, execute tailscale down
5.) From an SSH prompt, execute tailscale up --advertise-routes:192.168.50.0/24 (or whatever your local network subnet is)
6.) Open TAILMON back up again... everything is running as normal
7.) Starting/stopping connections works again as normal.

In the end, I think this --reset is what helped clear things out again... Gosh I hope this doesn't happen very often.

I tested a simpler version. Kernel mode.

• Checked Tailscale (D) brought it down whilst in Tailmon
• Checked Tailscale (U) failed to bring it up whilst in Tailmon
• Exited to CLI, ran tailscale up —reset
• Went back into Tailmon and tested D and U and D and U, all working fine.

So the simple tailscale up —reset did it for me, I did not change or run anything else.

I even checked the Tailmon (P) tailscale update routine (which didn’t update) but I think it just runs (D), then (U) anyway, and it worked fine too.

 

[Viktor Jaep]

I tested a simpler version. Kernel mode.

• Checked Tailscale (D) brought in down whilst in Tailmon
• Checked Tailscale (U) failed to bring it up whilst in Tailmon
• Exited to CLI, ran tailscale up —reset
• Went back into Tailmon and tested D and U and D and U, all working fine.

So the simple tailscale up —reset did it for me, I did not change or run anything else.

What are your thoughts... shall I add a "(N)uclear Reset (execute --reset)" to the menu for cases like this?

 

[jksmurf]

What are your thoughts... shall I add a "(N)uclear Reset (execute --reset)" to the menu for cases like this?

I’m not sure TBH as I don’t know what it would do to folks custom lines.

I know for my case, if there was an update (only) that after pressing (P), then as that routine runs (D), if at this point you make it do a simple tailscale —reset, as a single extra step then it hopefully just goes onto (U) as normal. In my case it preserves the tailscale up addresses and everything so it doesn’t need any more than that.

Maybe add that single line as a trial step then test it on the 3 modes. If it comes up and doesn’t throw an error and can be made to go D, U, D, U without issue (and without it changing folks custom lines in particular), then it’s a simple fix (for the update procedure anyway).

It might also be needed outside of the update procedure, but I’m not sure under what scenarios.

 

[jksmurf]

Actually what I think is happening with the reset is this:

• In 1.66.0 the default stateful-filtering parameter was on.
• To fix connectivity issues folks were told to issue tailscale up --stateful-filtering=false to turn it off.
• In 1.66.4 the default stateful-filtering parameter is already off.
• Issuing tailscale —reset thus has tailscale up --stateful-filtering=false (i.e. switched off) without needing to actively switch it off i.e. the ‘fix’ is automatically applied.

I’d almost venture to say (unless tailscale stuff it up again) this is a one-off thing and after folks have updated to 1.66.4 and issued tailscale —reset just the once, you won’t have to deal with it ever, ever again. Famous last words…

 

[oldsweatyman]

Hey everyone. Thanks for the great work. I'm running into an issue with trying to update tailscale. Running tailscalemon version 1.0.10 on an RT-AX86U. Using the amtm menu, I get the following:

Messages:

Executing: tailscale update

This will update Tailscale from 1.58 to 1.66.4. Continue? [y/n] y
Downloading "https://pkgs.tailscale.com/stable/tailscale_1.66.4_arm64.tgz"
Download size: 25784846
Get "https://dl.tailscale.com/stable/tailscale_1.66.4_arm64.tgz": net/http: TLS handshake timeout

Running 'wget "https://pkgs.tailscale.com/stable/tailscale_1.66.4_arm64.tgz"', i get the following, where it just hangs:

wget "https://pkgs.tailscale.com/stable/tailscale_1.66.4_arm64.tgz"
Will not apply HSTS. The HSTS database must be a regular and non-world-writable file.
ERROR: could not open HSTS store at '/root/.wget-hsts'. HSTS will be disabled.
--2024-05-22 21:46:39--  https://pkgs.tailscale.com/stable/tailscale_1.66.4_arm64.tgz
Resolving pkgs.tailscale.com... 199.38.181.239
Connecting to pkgs.tailscale.com|199.38.181.239|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://dl.tailscale.com/stable/tailscale_1.66.4_arm64.tgz [following]
--2024-05-22 21:46:39--  https://dl.tailscale.com/stable/tailscale_1.66.4_arm64.tgz
Resolving dl.tailscale.com... 109.105.218.17
Connecting to dl.tailscale.com|109.105.218.17|:443... connected.

Works outside of my internet connection of course. I'm running Skynet, Unbound, and Diversion, all of which I've turned off individually and turned off all 3 at the same time, none of which makes a difference. I don't appear to have any issues doing anything else in my network, so I can't figure out how else to troubleshoot or move forward. Any ideas?

 

[jksmurf]

Using the amtm menu

I’m assuming you mean Tailmon’s Tailscale update menu (C), (P)? (not amtm).

In any case, I’d hazard a guess it’s just the tailscale servers having a bad day; I used to have the manual download (using curl) hang on me from time to time. Maybe just give it another go in a wee while (using Tailmon)?

Or you could try https://pkgs.tailscale.com/stable/#static from a Browser and choose the arm64 package, just to see if it downloads for you? Extract and use WinSCP to copy it across (but strongly suggest you just use Tailmon).

Another alternative (better than the Browser option) is in the wiki instructions here.

 

[oldsweatyman]

I’m assuming you mean Tailmon’s Tailscale update menu (C), (P)? (not amtm).

In any case, I’d hazard a guess it’s just the tailscale servers having a bad day; I used to have the manual download (using curl) hang on me from time. Maybe just give it
another go in a wee while (using Tailmon)?

Yes, thanks for the correction, I am using the update menu (C), (P), not amtm. Will try again tomorrow. Although, using wget/curl on the same link (https://pkgs.tailscale.com/stable/tailscale_1.66.4_arm64.tgz) on a different network (laptop at work) works just fine. Even when I have tailscale connected and using my router as an exit node, it works on my laptop.

EDIT: I misspoke. When I use my router as the exit node on my laptop, the link does not download the file. When change the exit node setting on my laptop to another device on the same local network as my router, my unRAID server connected via ethernet to the router, the file does download. No clue what to make of that.

 

[jksmurf]

Yes, thanks for the correction, I am using the update menu (C), (P), not amtm. Will try again tomorrow. Although, using wget/curl on the same link (https://pkgs.tailscale.com/stable/tailscale_1.66.4_arm64.tgz) on a different network (laptop at work) works just fine. Even when I have tailscale connected and using my router as an exit node, it works on my laptop.

No worries, yes IIRC I only had that downloading error using wget/curl so maybe just something at Tailscale’s end that doesn’t like it.

 

[jksmurf]

EDIT: I misspoke. When I use my router as the exit node on my laptop, the link does not download the file. When change the exit node setting on my laptop to another device on the same local network as my router, my unRAID server connected via ethernet to the router, the file does download. No clue what to make of that.

I assume the current Tailscale instance on the router is actually running (in case that being down or stopped is itself causing the no connection, not sure how though) i.e. Tailscale is “alive”?

 

[oldsweatyman]

I assume the current Tailscale instance is running (in case that being down or stopped is itself causing the no connection?)

Correct. Sorry for the real-time repeat post edits, thanks for keeping up. I restarted tailscale and checked to ensure the connection is working before attempting the download. All other connections work fine with my router as the exit node, just not this download specifically. Ping works just fine as well with exit node set to my router.

ping dl.tailscale.com
PING dl.tailscale.com (109.105.218.17): 56 data bytes
64 bytes from 109.105.218.17: seq=0 ttl=52 time=28.114 ms
64 bytes from 109.105.218.17: seq=1 ttl=52 time=23.843 ms
64 bytes from 109.105.218.17: seq=2 ttl=52 time=31.625 ms
64 bytes from 109.105.218.17: seq=3 ttl=52 time=43.485 ms
^C
--- dl.tailscale.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 23.843/31.766/43.485 ms

 

[jksmurf]

Correct. Sorry for the real-time repeat post edits, thanks for keeping up. I restarted tailscale and checked to ensure the connection is working before attempting the download. All other connections work fine with my router as the exit node, just not this download specifically. Ping works just fine as well with exit node set to my router.

ping dl.tailscale.com
PING dl.tailscale.com (109.105.218.17): 56 data bytes
64 bytes from 109.105.218.17: seq=0 ttl=52 time=28.114 ms
64 bytes from 109.105.218.17: seq=1 ttl=52 time=23.843 ms
64 bytes from 109.105.218.17: seq=2 ttl=52 time=31.625 ms
64 bytes from 109.105.218.17: seq=3 ttl=52 time=43.485 ms
^C
--- dl.tailscale.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 23.843/31.766/43.485 ms

No worries. Give me a minute while I downgrade my version, then try the Tailmon update again. Back in a wee while.