What's new

[RELEASE] TAILMON v1.0.10 -May 12, 2024- WireGuard-based Tailscale Installer, Configurator and Monitor (Now available in AMTM!)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

C, then P for that part of your question.

Not sure about the first question, someone will hopefully answer correctly, but I believe it might be the accept-routes switch (TBC) which you can enable using a Custom cmd line.

Currently you select C, 3, 3, then you go e, y, it does a down / restart and then it will ask you about customizing settings. Then you can modify one or more of the 4 lines.

I'm facing the same challenge here.

You should definitely customize the Connection Commandline to accept routes by adding "-accept-routes=true" at the end of the command.

The issue then is that you'll be able to connect to any of the devices on the other side of the tunnel from the router (you can test it through a ping from the router to a machine in the other site subnet) but the routes will not be published for the other devices in your network.

I'm trying to understand how to route the traffic to the proper Subnet routes given the connected nodes to the Tailscale network, but I'm currently stuck on that.
 
What should I do If I want to use as site-2-site?
I'm trying to understand how to route the traffic to the proper Subnet routes given the connected nodes to the Tailscale network, but I'm currently stuck on that.

Use --advertise-routes and --accept-routes, then decide whether you want to disable SNAT and stateful filtering.

See recent security bulletin TS-2024-005 regarding stateful filtering. Stateful filtering was added in 1.66.0.
 
Last edited:
OK, I've got Tailscale working & doing what I want with TAILMON looking after it in the background.

I had a bit of hassle setting it up - I want it to run as an Exit-node but NOT to advertise-routes. The default setup on installation is to advertise-routes.

The problem is TAILMON failed to remove the advertise-routes option when I de-selected it on the config screen as you need to add the '--reset' flag when making this change.

You do get a message stating this, but it appears and is then cleared by TAILMON seconds later. It took me a couple of goes and some nifty select+copy commands before I could grab it and read what it said.

I was then able to run "tailscale up --advertise-exit-node --reset" outside TAILMON and that sorted everything out.
 
OK, I've got Tailscale working & doing what I want with TAILMON looking after it in the background.

I had a bit of hassle setting it up - I want it to run as an Exit-node but NOT to advertise-routes. The default setup on installation is to advertise-routes.

The problem is TAILMON failed to remove the advertise-routes option when I de-selected it on the config screen as you need to add the '--reset' flag when making this change.

You do get a message stating this, but it appears and is then cleared by TAILMON seconds later. It took me a couple of goes and some nifty select+copy commands before I could grab it and read what it said.

I was then able to run "tailscale up --advertise-exit-node --reset" outside TAILMON and that sorted everything out.
Nice job, @alan6854321 ... Yeah, when you're doing something custom like that, knowing that you have to run --reset commands like that will typically need to be made using a separate commandline. TAILMON is really there to setup and maintain a stable connection that doesn't involve multiple changes to the commandline... When you are adding and deleting switches, you may have to play with it offline a bit until you've settled on some commands you want TAILMON to maintain. ;)
 
@ColinTaylor , @thelonelycoder I know this is the wrong thread for this, but I just wanted to follow up with some info about the 'bad' Entware install I had.

I still have backups of the USB drive from when it was used in my AX86S.
Those backups DO contain /entware/etc/init.d/rc.func

But the 'oldest' backup I have of my AX88U Pro does not even have the /entware/etc/init.d folder on it. ( /entware/etc is there )

This would have been after I plugged it into the AX88U Pro and amtm did the "I've found an existing version of Entware" thing.

So it would seem that the /entware/etc/init.d folder actually got deleted somewhere in the process.
 
But the 'oldest' backup I have of my AX88U Pro does not even have the /entware/etc/init.d folder on it. ( /entware/etc is there )
Does this backup have /entware/bin/opkg and /entware/etc/opkg.conf ?

Can you list the files in this backup in /entware/etc/ please?
 
Does this backup have /entware/bin/opkg and /entware/etc/opkg.conf ?
Both files are present.

Code:
/entware/bin $ ls -l
total 4448
-rwxr-xr-x 1 pi pi  138264 Feb 22 18:13 dig
-rwxr-xr-x 1 pi pi   31720 Feb 22 18:13 fuser
-rwxr-xr-x 1 pi pi  285440 Feb 22 18:13 htop
-rwxr-xr-x 1 pi pi   60976 Feb 22 18:13 iftop
-rwxr-xr-x 1 pi pi  343080 Feb 22 18:13 jq
lrwxrwxrwx 1 pi pi      20 Mar  9 13:45 killall -> /opt/libexec/killall
-rwxr-xr-x 1 pi pi   47704 Feb 22 18:13 mosquitto_pub
-rwxr-xr-x 1 pi pi   52016 Feb 22 18:13 mosquitto_rr
-rwxr-xr-x 1 pi pi   52016 Feb 22 18:13 mosquitto_sub
-rwxr-xr-x 1 pi pi 2615600 Feb 22 18:13 nmap
-rwxr-xr-x 1 pi pi  856112 Feb 24 13:09 opkg
-rwxr-xr-x 1 pi pi   14520 Feb 22 18:13 prtstat
-rwxr-xr-x 1 pi pi   10384 Feb 22 18:13 pslog
-rwxr-xr-x 1 pi pi   27280 Feb 22 18:13 pstree
lrwxrwxrwx 1 pi pi      22 Mar 10 18:51 scmerlin -> /jffs/scripts/scmerlin
lrwxrwxrwx 1 pi pi      30 Mar 15 16:24 timeout -> /opt/libexec/timeout-coreutils
lrwxrwxrwx 1 pi pi      21 Mar  9 13:17 YazDHCP -> /jffs/scripts/YazDHCP

Code:
/entware/etc $ ls -la
total 28
drwxr-xr-x  3 pi pi 4096 Apr 19 14:56 .
drwxr-xr-x 10 pi pi 4096 Feb 22 18:13 ..
lrwxrwxrwx  1 pi pi   10 Mar  9 13:15 group -> /etc/group
lrwxrwxrwx  1 pi pi   12 Mar  9 13:15 gshadow -> /etc/gshadow
lrwxrwxrwx  1 pi pi   14 Mar  9 13:15 localtime -> /etc/localtime
-rw-r--r--  1 pi pi  282 Sep 17  2020 nsswitch.conf
-rw-r--r--  1 pi pi  181 Apr 19 14:56 opkg.conf
lrwxrwxrwx  1 pi pi   11 Mar  9 13:15 passwd -> /etc/passwd
-rw-r--r--  1 pi pi   36 Mar  9 13:45 profile
-rw-r--r--  1 pi pi   20 Feb 22 18:13 screenrc
lrwxrwxrwx  1 pi pi   11 Mar  9 13:15 shadow -> /etc/shadow
drwxr-xr-x  4 pi pi 4096 Mar 16 15:37 ssl
 
So it would seem that the /entware/etc/init.d folder actually got deleted somewhere in the process.
There is nothing in my code that can or does delete files when reusing an existing entware folder on a device.
 
I was then able to run "tailscale up --advertise-exit-node --reset" outside TAILMON and that sorted everything out.
After resetting this from the Cmd line did you then use the custom menu to setup your exit node only? Asking as Tailmon has a nifty option to preserve settings on reboot and I would imagine this includes the Custom tailscale up setting (only?)
 
Finally got around to installing and configuring TAILMON for the first time. Using custom mode with subnet routes on, exit node on, and accept dns=false. Works brilliantly! Thank you, all!
 
After resetting this from the Cmd line did you then use the custom menu to setup your exit node only?
Yes I did, and I tested it with a reboot.
Tailscale came back up with the correct options (Exit-node, no advertise-routes)

Thinking about it, I wonder why TALIMON doesn't use the '--reset' flag whenever the options are changed?
 
@Viktor Jaep thank you for your work. Small comment from my side: I think there is far too much `sleep` commands in the script, which introduces artificial lag and slow downs in the whole script which is not needed.

//Not related to script: had some issues with forwarding traffic from devices in my network through tailscale interface after updating to 1.66.1. After downgrading to version from opkg it works again (iptables -t nat -A POSTROUTING -o tailscale0 -j MASQUERADE)
 
Last edited:
I think there is far too much `sleep` commands in the script, which introduces artificial lag and slow downs in the whole script which is not needed.
I’ll put my hand up here, I asked for these during testing but they’re probably not needed anymore.

I realised that it probably wasn’t due to the service needing time to start, but rather because (following the 1.58.2-1 entware to 1.6x Tailscale update) that it was trying to find directories that weren’t created until the daemon started up. Sleeping the install does not help with that. Hopefully that makes sense.

Viktor can probably remove them all now; not sure if the error message needs suppressing too.
 
Last edited:
Viktor can probably remove them all now; not sure if the error message needs suppressing too.
Maybe, but he needs to add extra ones where an error message has to be read.
Especially a long one (Like the "--reset" message I posted about earlier)

In fact, messages like that really need a "Press any key to continue" type thing.
 
Some minor changes made based on feedback from @jksmurf and @snz... enjoy!

What's new:
v1.0.10 - (May 12, 2024)
- PATCH:
Made some wording changes based on feedback from @jksmurf in the Operation Mode screen, which now explicitly states that changes are made upon exit, and that if the 'Custom' mode is selected, that you will be able to make changes to custom settings after TAILMON completes making changes.
- PATCH: Reduced the number of sleep timeouts based on feedback from @snz. This will reduce the amount of time you have to receive feedback on what the application is currently doing, but will give you the perception that its running faster now. Certain things I do not have control over: ie. the time it takes for Tailscale services/connection to stop and start, etc.

Download link (or update directly within TAILMON or AMTM):
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/TAILMON/master/tailmon.sh" -o "/jffs/scripts/tailmon.sh" && chmod 755 "/jffs/scripts/tailmon.sh"

Significant Screenshots:

Added some wording to explain when changes are made, and when to expect a custom configuration screen
1715530604149.png
 
Use --advertise-routes and --accept-routes, then decide whether you want to disable SNAT and stateful filtering.

See recent security bulletin TS-2024-005 regarding stateful filtering. Stateful filtering was added in 1.66.0.

I added "--accept-routes=true" in "Tailscale Connection commandline" for both routers but still can't ping devices under routers. Any more detail step-by-step guide for this purpose? Thanks in advance.
T1.jpg


T2.jpg
 
I added "--accept-routes=true" in "Tailscale Connection commandline" for both routers but still can't ping devices under routers. Any more detail step-by-step guide for this purpose? Thanks in advance.
Not really my field, but have you tried adding the --snat-subnet-routes=false option to both your subnet routers; although it did not seem to help the OP in that thread, sorry.

 
I added "--accept-routes=true" in "Tailscale Connection commandline" for both routers but still can't ping devices under routers. Any more detail step-by-step guide for this purpose? Thanks in advance.
Did you approve the routes in the Tailscale console?
 
Running into a few kinks and I can’t quite figure out why.

Prior to having Tailscale on my AX86U via TAILMON, I ran subnet routes through one of my Tailscale-enabled Raspberry Pis, primarily for the purpose of accessing my router and a few RPi-based servers when outside my home. Everything seemed to work great.

But now that I’m running the subnet routes directly from the Tailscale-enabled AX86U, I can’t seem to access the RPis at their local IP addresses when outside the home. I’m using the same flags I’ve always used on the Raspberry Pi (--accept-dns=false --advertise-routes=192.168.50.0/24), and the subnet routes have been approved in the Tailscale console.

Not sure what the issue is.
 
Hi @phneeley
Sounds like you had and now you have a similar setup to mine. I guess a couple of questions:

A) Did you approve the subnet routes within the tailscale console web page?

B) How are you trying to access your devices, via IP or hostnames or FQDN?

When I transferred from RPI only to Router based tailscale I just chose the normal install over anything customised for tailmon, and added no extra parameters. Tailscale console recognised my router and the fact I needed to approve the subnet routes it was advertising (192.168.x.x).

After a few days I also just stopped my tailscale service on my RPI as I wanted to access the RPI via the router not directly and I changed my DNS override settings within tailscale console to utilise my dual piholes.

Things are working fine for me, apart from I did have a similar issue to you but found for some reason in tailmon the tailscale service had stopped. Started again and all has been fine since.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top