Was the software title installed freshly or updated/migrated? freshly
Steps to reproduce
After installing Tailscale on Dietpi, I wanted to make the RPi a “Subnet Router” so that I can connect two different networks. I had this working with an installation of tailscale on Raspian, before I upgraded the RPi to use Dietpi, so the only thing that has changed in my set up is the use of Dietpi instead of Raspian or Raspberry Pi OS. Everything on the Dietpi install looks like it is setup correctly.
With the install of Tailscale on Dietpi it appears that IP forwarding is already enabled correctly, but I double checked that.
In the Tailscale interface it is listed as a “Subnet” router and the route is approved, “10.0.1.0/24”.
My networks are setup:
Home = 192.168.1.0/24
Office = 10.0.1.0/24
I can ssh and bring up webpages hosted on Home network using the IP’s 192.168.1.1 or others. I have a box running PFsense and Tailscale acting as a Subnet router on the home network, and that seems to be working as expected.
I can’t ssh or bring up webpage hosted on Office network using the IP’s 10.0.1.1 or others. My dietpi is at the office at the IP 10.0.1.253. I can reach the dietpi by ssh by using the IP that it was assigned in the Tailscale interface.
Any tips on what configuration setting I might have missed?
I don’t have anything else installed on the Dietpi besides the base installation, git, and Tailscale. I use the RPi as my personal git server as well but just running git bare repos without a web interface, hence why just git is installed and not something like Gitea.
I could try to “reapprove” the routes in the Tailscale interface, but it shows it as approved and ready to work.
I went through the linked tutorial on Tailscale site again, did everything they said to do after I first went into the web interface, and unchecked the advertised route and “saved” under “Approved”
After going through the tutorial setup, I once again went to the Tailscale web interface, and clicked on “Edit” link for “Awaiting Approval” and clicked on the advertised route and saved again.
I also rebooted the RPi.
Still can’t ssh into the box using 10.0.1.253 or even ping 10.0.1.253 and get a response from my home network.
Is there a firewall running on a base dietpi install that could interfere? I couldn’t find one running in the processes, but maybe I was looking for the wrong name of the firewall. Also I am able to use the Tailscale IP address to ssh into the box.
hmm I did a test on a spare OPi5 SBC and it was working ootb. Our install script is already enabling IP forwarding to allow access across network interfaces.
[ OK ] DietPi-Software | APT install tailscale
[ INFO ] DietPi-Software | Enabling IP forwarding to allow access across network interfaces
net.ipv4.ip_forward = 1
net.ipv6.conf.default.accept_ra = 2
net.ipv6.conf.all.accept_ra = 2
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
DietPi-Software
─────────────────────────────────────────────────────
Step: Finalising install
Therefore nothing to do on this side.
The only thing I did was adding my OPi5 to tailscale network
root@DietPiOPi5:~# tailscale up --advertise-routes=192.168.0.0/24
To authenticate, visit:
https://login.tailscale.com/a/id_xxx
Success.
root@DietPiOPi5:~#
Followed by approving the route on tailscale admin panel
Now I’m able to connect from my mobile phone via SSH to other device on my local network. On a different DietPi system I see SSH login attempt from OPi5 system (192.168.0.22)
@Joulinar, I started looking into whether or not it might not be dietpi, but something else. Although I haven’t changed any of the configuration on my Pfsense box that is running on my “Home” network, I’m wondering if that is the issue since I can’t go from “Home” to “Office” IP’s, but I can go from “Office” to “Home” IP’s. I ran traceroute and got the following output =
The traceroute never jumps from the Pfsense box to even my ISP provider boxes, even though the Pfsense setup looks solid and obviously works for inbound traffic, and there is a configuration for outbound traffic requesting 10.0.1.0/24 to go through the Tailscale interface.
I have posted on the Netgate forum about it, hoping they might have some insight.
Of course, my knowledge is only what can fill a single Google search request when it comes to traceroute so I might be misunderstanding things.
This sounds like a great idea, but I have no idea how to test this. I have my home computer connected to my phone hotspot, and the phone wifi turned off. But my computer or my phone have no way of knowing how to get to the “Office” network and the RPi by using the 10.0.1.253 address.
On the “Home” network the Pfsense box is supposed to forward all requests for “10.0.1.0/24” routes to the tailscale network. On the “Office” network the work Firewall is supposed to forward all requests for “192.168.1.0/24” routes to the RPi running on the network at “10.0.1.253”. By trying to eliminate the Pfsense box, I’m unsure how to test connection to the “Office” network. I can ssh to the RPi using the Tailscale IP address, but that isn’t the behavior I’m trying to achieve.
Sorry, my understanding of networking is beginner level probably.
Output from sudo iptables -S on the RPi at the “Office” running dietpi.
$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N ts-forward
-N ts-input
-A INPUT -j ts-input
-A FORWARD -j ts-forward
-A ts-forward -i tailscale0 -j MARK --set-xmark 0x40000/0xff0000
-A ts-forward -m mark --mark 0x40000/0xff0000 -j ACCEPT
-A ts-forward -s 100.64.0.0/10 -o tailscale0 -j DROP
-A ts-forward -o tailscale0 -j ACCEPT
-A ts-input -s 100.***.***.***(Obscured IP address for RPi at "Office")/32 -i lo -j ACCEPT
-A ts-input -s 100.115.92.0/23 ! -i tailscale0 -j RETURN
-A ts-input -s 100.64.0.0/10 ! -i tailscale0 -j DROP
-A ts-input -i tailscale0 -j ACCEPT
-A ts-input -p udp -m udp --dport 41641 -j ACCEPT
I only recognize one of the IP addresses in the output above which I have obscured. The rest of the IP’s I’m not sure why they are in there or what purpose they serve.
@Joulinar,
I was just talking to my son about this, and he reminded me that the rules that are in the different firewalls, Pfsense at “Home” and the “Office” firewall only come into use when computers that don’t have Tailscale installed are trying to access the different computers on the different networks.
So, since I have Tailscale installed and working on my main Linux Workstation at home, and since I can reach the RPi from this “Home” Linux Workstation using the Tailscale IP that the RPi running Dietpi has, then I should have been able to access the RPi using its “advertised route” IP of 10.0.1.253 when I was connected to just my cell phone’s network by the wifi hotspot on my phone. So the issue must be on the Dietpi because any computer on my Tailscale network should be able to see the RPi advertising those routes and should be able to connect using those IP addresses.
Additionally, the computer (“home workstation”) that I’m trying to access the RPi (running dietpi) on the “Office” network also has Tailscale installed, so it doesn’t need the Pfsense box to have a connection to the RPi because it can connect with it directly through its own Tailscale interface.
Below is output from the RPi (I can’t run this command on Pfsense because it is FreeBSD based), but I know that I can access “Home” network through the Pfsense box when I’m on the “Office” network. I can’t access the “Office” network when I’m on the “Home” network or any network, I have tried by connecting through my cellular connection as well.
Output below, I think the answer is yes, from the way I read the output. (Once again, I can’t run this on the Pfsense box, but it shouldn’t be an issue, because my “home workstation” should be able to see the advertised routes of for the 10.0.1.0/24 network.
$ ip -4 addr; ip -4 ro list table all; ip -4 ru
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 10.0.1.253/24 brd 10.0.1.255 scope global eth0
valid_lft forever preferred_lft forever
4: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
inet 100.(TailscaleIP for RPi)/32 scope global tailscale0
valid_lft forever preferred_lft forever
100.(TailscaleIP for device on TS network) dev tailscale0 table 52
100.(TailscaleIP ") dev tailscale0 table 52
100.(TailscaleIP ") dev tailscale0 table 52
100.(TailscaleIP ") dev tailscale0 table 52
100.100.100.100 dev tailscale0 table 52
100.(TailscaleIP ") dev tailscale0 table 52
100.(TailscaleIP ") dev tailscale0 table 52
100.(TailscaleIP ") dev tailscale0 table 52
100.(TailscaleIP for Pfsense) dev tailscale0 table 52
192.168.1.0/24 dev tailscale0 table 52
default via 10.0.1.1 dev eth0 onlink
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.253
local 10.0.1.253 dev eth0 table local proto kernel scope host src 10.0.1.253
broadcast 10.0.1.255 dev eth0 table local proto kernel scope link src 10.0.1.253
local 100.(TailscaleIP for RPi) dev tailscale0 table local proto kernel scope host src 100.(TailscaleIP for RPi)
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
0: from all lookup local
5210: from all fwmark 0x80000/0xff0000 lookup main
5230: from all fwmark 0x80000/0xff0000 lookup default
5250: from all fwmark 0x80000/0xff0000 unreachable
5270: from all lookup 52
32766: from all lookup main
32767: from all lookup default
Answer appears to be yes as I look at the output below.
$ sudo iptables-save -c
# Generated by iptables-save v1.8.9 (nf_tables) on Fri Jul 19 11:34:27 2024
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:ts-forward - [0:0]
:ts-input - [0:0]
[57814:20162827] -A INPUT -j ts-input
[0:0] -A FORWARD -j ts-forward
[0:0] -A ts-forward -i tailscale0 -j MARK --set-xmark 0x40000/0xff0000
[0:0] -A ts-forward -m mark --mark 0x40000/0xff0000 -j ACCEPT
[0:0] -A ts-forward -s 100.64.0.0/10 -o tailscale0 -j DROP
[0:0] -A ts-forward -o tailscale0 -j ACCEPT
[0:0] -A ts-input -s 100.(TailscaleIP for RPi)/32 -i lo -j ACCEPT
[0:0] -A ts-input -s 100.115.92.0/23 ! -i tailscale0 -j RETURN
[0:0] -A ts-input -s 100.64.0.0/10 ! -i tailscale0 -j DROP
[984:87367] -A ts-input -i tailscale0 -j ACCEPT
[1544:192088] -A ts-input -p udp -m udp --dport 41641 -j ACCEPT
COMMIT
# Completed on Fri Jul 19 11:34:27 2024
# Generated by iptables-save v1.8.9 (nf_tables) on Fri Jul 19 11:34:27 2024
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:ts-postrouting - [0:0]
[1127:85539] -A POSTROUTING -j ts-postrouting
[0:0] -A ts-postrouting -m mark --mark 0x40000/0xff0000 -j MASQUERADE
COMMIT
# Completed on Fri Jul 19 11:34:27 2024
Some of the IP addresses above look like they are coming from Tailscale, so I don’t know if that gives some indication of what is happening. Perhaps the RPi running Dietpi is blocking incoming Tailscale traffic?
I know that it is not blocking all Tailscale traffic because I’m running this commands from my “Home” network connected to the RPi using its TailscaleIP address to ssh into it.
What I can’t do is access the RPi using its advertised routes of “10.0.1.0/24” or its network IP address of 10.0.1.253.
I think I know what is wrong, but I need to see the addresses you have masked. The 100.64-127.X.Y addresses are private, like 10.X.Y.Z or 192.168.Y.X, so you don’t risk your privacy by posting them here.
Also on pfsense run the netstat -rn to verify the routing table.
@trendy, okay, I will trust you. I wasn’t sure if showing them was like revealing your public IP address to the world.
Output below from RPi
$ ip -4 addr; ip -4 ro list table all; ip -4 ru
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 10.0.1.253/24 brd 10.0.1.255 scope global eth0
valid_lft forever preferred_lft forever
4: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
inet 100.76.129.117/32 scope global tailscale0
valid_lft forever preferred_lft forever
100.65.52.27 dev tailscale0 table 52
100.75.187.148 dev tailscale0 table 52
100.84.10.72 dev tailscale0 table 52
100.84.192.72 dev tailscale0 table 52
100.100.100.100 dev tailscale0 table 52
100.116.143.61 dev tailscale0 table 52
100.119.27.72 dev tailscale0 table 52
100.121.120.57 dev tailscale0 table 52
100.123.76.140 dev tailscale0 table 52
192.168.1.0/24 dev tailscale0 table 52
default via 10.0.1.1 dev eth0 onlink
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.253
local 10.0.1.253 dev eth0 table local proto kernel scope host src 10.0.1.253
broadcast 10.0.1.255 dev eth0 table local proto kernel scope link src 10.0.1.253
local 100.76.129.117 dev tailscale0 table local proto kernel scope host src 100.76.129.117
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
0: from all lookup local
5210: from all fwmark 0x80000/0xff0000 lookup main
5230: from all fwmark 0x80000/0xff0000 lookup default
5250: from all fwmark 0x80000/0xff0000 unreachable
5270: from all lookup 52
32766: from all lookup main
32767: from all lookup default
Output below from RPi
$ sudo iptables-save -c
# Generated by iptables-save v1.8.9 (nf_tables) on Fri Jul 19 12:16:18 2024
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:ts-forward - [0:0]
:ts-input - [0:0]
[59882:20639908] -A INPUT -j ts-input
[0:0] -A FORWARD -j ts-forward
[0:0] -A ts-forward -i tailscale0 -j MARK --set-xmark 0x40000/0xff0000
[0:0] -A ts-forward -m mark --mark 0x40000/0xff0000 -j ACCEPT
[0:0] -A ts-forward -s 100.64.0.0/10 -o tailscale0 -j DROP
[0:0] -A ts-forward -o tailscale0 -j ACCEPT
[0:0] -A ts-input -s 100.76.129.117/32 -i lo -j ACCEPT
[0:0] -A ts-input -s 100.115.92.0/23 ! -i tailscale0 -j RETURN
[0:0] -A ts-input -s 100.64.0.0/10 ! -i tailscale0 -j DROP
[1275:110648] -A ts-input -i tailscale0 -j ACCEPT
[2057:259592] -A ts-input -p udp -m udp --dport 41641 -j ACCEPT
COMMIT
# Completed on Fri Jul 19 12:16:18 2024
# Generated by iptables-save v1.8.9 (nf_tables) on Fri Jul 19 12:16:18 2024
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:ts-postrouting - [0:0]
[1296:98655] -A POSTROUTING -j ts-postrouting
[0:0] -A ts-postrouting -m mark --mark 0x40000/0xff0000 -j MASQUERADE
COMMIT
# Completed on Fri Jul 19 12:16:18 2024
All good here, can you run a packet capture on RPi, while you are trying to access some office LAN device from home LAN? The IPs are for example, change with yours.
apt update
apt install tcpdump
tcpdump -i any -vnn host 192.168.1.123 and host 10.0.1.123
@trendy I ran the commands that you suggested, and tried pinging from 192.168.1.95 to a Linux workstation that I knew was on at 10.0.1.251, and curl something hosted on that machine, but the output that I got is the following, it doesn’t seem to tell me much the 10.0.1.253 is the RPi:
sudo tcpdump -i any -vnn host 192.168.1.95 and host 10.0.1.253
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
^C
0 packets captured
4 packets received by filter
0 packets dropped by kernel
However, after upgrading Dietpi yesterday and rebooting it, I think it might be working as a subrouter now. Of course, I had done the same thing several times before I asked this question in the forums, but I believe it is working now after a few weeks of not touching it at all and then upgrading yesterday, but I will run some more tests to make sure that it is not just my imagination.
