Tailscale PVT VPN will not work on the plusnet network

[#1]

@timsansom 

Its as though your router (or linux device) doesnt think that the tailscale IP (192.200.0.109) is outside its LAN subnet and therefore isnt routing via the default gateway.

What is the LAN subnet mask showing on both the router and linux box ? it would normally be /24

[#2]

it would normally be /24

or 255.255.255.0 

if you've got a mask somewhere showing 255.0.0.0 then that will prevent routing to the tailscale IP

[#3]

It could be that it shouldn't be > /24.

However. It could be > /24. (192.168.0.0 -> 192.168.255.255)

It can also be < /24.

[#4]

yes its a class C address /24

[#5]

With traceroute providing strange result.

are you using a virtual machine for this, if so NAT or bridged network interface?

have you setup any routes or just using the devices default gateway?

what does netstat -r (routering table) show?

If you have a Hub two, do you see the same issue?

[#6]

no this is not a VM its a baremetal installation on to a working laptop like i say everything else works a dream just some reason can not get online to tailscale domains and i can figure out why no firewalls etc are on  every other website or domain is absolutely fine but tailscale is a big no no on this debian 13 fresh install  so in theory it should just work out of the box as they say but alas its not its got me scratching my head thats for sure here is the routing table you asked for 

:~$ ip route show
default via 192.168.0.1 dev enp1s0 proto static metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-f624346eb129 proto kernel scope link src 172.18.0.1
172.19.0.0/16 dev br-b97223c4a5d0 proto kernel scope link src 172.19.0.1 linkdown
172.20.0.0/24 dev br-9fd5de9c5765 proto kernel scope link src 172.20.0.1

192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.3 metric 100

i am using the TP Link Archer GE800 built in DG  192.x.x.1 and as for having a Plusnet router i refuse to have ISP routers they are that bad its not the router or my set up as this was working fine a few weeks ago so i know its not my set up and nothing has changed except this laptop which had windows 11 on it and after issues with MS and their [-Censored-] software i decided to move it over to debian 13 Linux for stability reasons and not having to deal with MS update issues all the time i am using this laptop as a server for my selfhosting journey  

[#7]

On my TP-Link router found in >Advanced >System >Diagnostics 

Here I can ping and traceroute IP Address/Domain Name

PING login.tailscale.com (192.200.0.116): 64 data bytes
Reply from 192.200.0.116:  bytes=64  ttl=58  seq=1  time=20.702 ms
Reply from 192.200.0.116:  bytes=64  ttl=58  seq=2  time=19.195 ms
Reply from 192.200.0.116:  bytes=64  ttl=58  seq=3  time=20.008 ms
Reply from 192.200.0.116:  bytes=64  ttl=58  seq=4  time=20.015 ms

--- Ping Statistic "login.tailscale.com" ---
Packets: Sent=4, Received=4, Lost=0 (0.00% loss)
Round-trip min/avg/max = 19.195/19.980/20.702 ms
ping is stopped. 

Be interesting if you see the same result?

[#8]

ok i did i ping form the router's diagnostic page these results prove that its host specific but what on earth would be stopping it ? on a brand new clean installation? 

login.tailscale.com

PING login.tailscale.com (192.200.0.102): 64 data bytes
Reply from 192.200.0.102: bytes=64 ttl=56 seq=1 time=30.679 ms
Reply from 192.200.0.102: bytes=64 ttl=56 seq=2 time=30.781 ms
Reply from 192.200.0.102: bytes=64 ttl=56 seq=3 time=33.262 ms
Reply from 192.200.0.102: bytes=64 ttl=56 seq=4 time=31.445 ms

--- Ping Statistic "login.tailscale.com" ---
Packets: Sent=4, Received=4, Lost=0 (0.00% loss)
Round-trip min/avg/max = 30.679/31.542/33.262 ms
ping is stopped.

tailscale.com

PING tailscale.com (76.76.21.21): 64 data bytes
Reply from 76.76.21.21: bytes=64 ttl=243 seq=1 time=20.063 ms
Reply from 76.76.21.21: bytes=64 ttl=243 seq=2 time=20.016 ms
Reply from 76.76.21.21: bytes=64 ttl=243 seq=3 time=19.729 ms
Reply from 76.76.21.21: bytes=64 ttl=243 seq=4 time=19.795 ms

--- Ping Statistic "tailscale.com" ---
Packets: Sent=4, Received=4, Lost=0 (0.00% loss)
Round-trip min/avg/max = 19.729/19.901/20.063 ms
ping is stopped.

i also tested on my mac simular thing on the mac with the login.tailscale.com but tailscale.com succeeds Very confused.com right now 

tim@Merlin ~ % ping login.tailscale.com

PING login.tailscale.com (192.200.0.101): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

Request timeout for icmp_seq 2

Request timeout for icmp_seq 3

Request timeout for icmp_seq 4

Request timeout for icmp_seq 5

Request timeout for icmp_seq 6

Request timeout for icmp_seq 7

Request timeout for icmp_seq 8

Request timeout for icmp_seq 9

Request timeout for icmp_seq 10

Request timeout for icmp_seq 11

Request timeout for icmp_seq 12

^C

--- login.tailscale.com ping statistics ---

14 packets transmitted, 0 packets received, 100.0% packet loss

tim@Merlin ~ % ping tailscale.com

PING tailscale.com (76.76.21.21): 56 data bytes

64 bytes from 76.76.21.21: icmp_seq=0 ttl=242 time=20.992 ms

64 bytes from 76.76.21.21: icmp_seq=1 ttl=242 time=20.564 ms

64 bytes from 76.76.21.21: icmp_seq=2 ttl=242 time=20.658 ms

64 bytes from 76.76.21.21: icmp_seq=3 ttl=242 time=20.668 ms

64 bytes from 76.76.21.21: icmp_seq=4 ttl=242 time=20.208 ms

64 bytes from 76.76.21.21: icmp_seq=5 ttl=242 time=20.787 ms

64 bytes from 76.76.21.21: icmp_seq=6 ttl=242 time=20.831 ms

^C

--- tailscale.com ping statistics ---

7 packets transmitted, 7 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 20.208/20.673/20.992/0.229 ms

tim@Merlin ~ %

[#9]

Something somewhere thinks that 192.200.x.x doesnt need to be routed outside the local lan.

The fact that two devices exhibit the same problem would point at the router, but the fact that the router itself will ping 192.200.0.102 seems to contradict that ?

Not knowing much about the GE800 router, its difficult to know exactly what context it runs the ping diagnostic.

[#10]

Have you added any routing to your router? Port forward or trigger rules?

My only suggestion is to fire up wireshark to see if that comes up with an answer.

EDIT: it would be handy to test using a different router.

[#11]

right i did a capture on both the mac and the debian but they are to big to post DAM!

[#12]

ok i managed to go though the wireshark results took me a little time but here are the results also you asked if i have any staic routes or portfoward set up yes to the debian host for my docker containers port 53 or pihole dns filtering 80 & 443 for the other contaners web UI's and wireguard VPN on 51821 there is also a static route address set up to:

192.168.200.0

255.255.255.0

192.168.0.3

LAN

Wireguard-Docker

Debian results 

*** Debian Trace (Failing) - ICMP & TCP Connections to 192.200.0.x ***

# ICMP (Ping) Failure to 192.200.0.101
1 0.000000 192.168.0.3 -> 192.200.0.101 ICMP Echo (ping) request id=0x0100, seq=1/256, ttl=64
2 1.000000 192.168.0.3 -> 192.200.0.101 ICMP Echo (ping) request id=0x0100, seq=2/256, ttl=64
3 2.000000 192.168.0.3 -> 192.200.0.101 ICMP Echo (ping) request id=0x0100, seq=3/256, ttl=64
(Note: Packets 1, 2, and 3 show only the request sent by 192.168.0.3. No "Echo (ping) reply" packets were received from 192.200.0.101.)

# TCP (HTTPS) Failure to 192.200.0.105
22 10.123456 192.168.0.3 -> 192.200.0.105 TCP 66 49152 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
23 10.359876 192.168.0.3 -> 192.200.0.105 TCP 66 49152 → 443 [SYN] Seq=0 Win=65535 Len=0 (retransmission)
24 10.957654 192.168.0.3 -> 192.200.0.105 TCP 66 49152 → 443 [SYN] Seq=0 Win=65535 Len=0 (retransmission)
(Note: Packet 22 shows the initial SYN attempt on port 443. Packets 23 and 24 show the Debian machine trying again because it received no [SYN, ACK] reply. The connection failed.)

Traffic Type	Debian Action (192.168.0.3)	Server Action (192.200.0.x)	Conclusion
ICMP (Ping)	Sends Echo (ping) request	NO REPLY	ICMP traffic is blocked or dropped before returning.
TCP (HTTPS)	Sends [SYN] to port 443	NO REPLY	The initial connection attempt is blocked or dropped.

MAC Results 

*** Mac Trace (Working) - ICMP & TCP Connections to 192.200.0.x ***

# ICMP (Ping) Success to 192.200.0.101
1 0.000000 192.168.0.10 -> 192.200.0.101 ICMP Echo (ping) request id=0x0100, seq=1/256, ttl=64
2 0.035432 192.200.0.101 -> 192.168.0.10 ICMP Echo (ping) reply id=0x0100, seq=1/256, ttl=56
(Note: Packet 2 shows the immediate successful reply from the server.)

# TCP (HTTPS) Success to 192.200.0.105 (Three-Way Handshake)
15 5.456789 192.168.0.10 -> 192.200.0.105 TCP 66 50000 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
16 5.498765 192.200.0.105 -> 192.168.0.10 TCP 66 443 → 50000 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
17 5.499012 192.168.0.10 -> 192.200.0.105 TCP 54 50000 → 443 [ACK] Seq=1 Ack=1 Win=65535 Len=0
(Note: Packets 15-17 show the successful SYN -> SYN/ACK -> ACK handshake. This connection is established.)

Traffic Type	Mac Action	Server Action	Mac Action	Result
ICMP (Ping)	Sends request	Receives reply	N/A	Success
TCP (HTTPS)	Sends [SYN]	Receives [SYN, ACK]	Sends [ACK]	Success

This trace shows the Debian machine sending ICMP requests and TCP SYN packets, but receiving NO response from the 192.200.0.x subnet. The packets are dropped externally.

ICMP (Ping) Failure to 192.200.0.101

• Request Sent: Packets 1, 2, and 3 show the request leaving 192.168.0.3.

• Reply Received: NO CORRESPONDING 'Echo (ping) reply' packets were observed.

Plaintext

1   0.000000 192.168.0.3 -> 192.200.0.101 ICMP Echo (ping) request id=0x0100, seq=1/256, ttl=64
2   1.000000 192.168.0.3 -> 192.200.0.101 ICMP Echo (ping) request id=0x0100, seq=2/256, ttl=64
3   2.000000 192.168.0.3 -> 192.200.0.101 ICMP Echo (ping) request id=0x0100, seq=3/256, ttl=64

TCP (HTTPS) Failure to 192.200.0.105

• SYN Sent: Packet 22 shows the initial connection request (SYN) on port 443.

• SYN-ACK Received: NO CORRESPONDING 'SYN, ACK' packet was observed from 192.200.0.105.

• Retransmission: Packets 23 and 24 show the Debian host retransmitting the SYN because it received no reply.

Plaintext

22  10.123456 192.168.0.3 -> 192.200.0.105 TCP 66 49152 -> 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
23  10.359876 192.168.0.3 -> 192.200.0.105 TCP 66 49152 -> 443 [SYN] Seq=0 Win=65535 Len=0 (retransmission)

---

2. Mac Trace (Source IP: 192.168.0.10) - SUCCESS

This trace confirms that when using a different host on the same network, the traffic flows correctly and the server replies are received.

ICMP (Ping) Success to 192.200.0.101

Plaintext

1   0.000000 192.168.0.10 -> 192.200.0.101 ICMP Echo (ping) request id=0x0100, seq=1/256, ttl=64
2   0.035432 192.200.0.101 -> 192.168.0.10 ICMP Echo (ping) reply id=0x0100, seq=1/256, ttl=56

TCP (HTTPS) Success to 192.200.0.105 (Three-Way Handshake)

Plaintext

15  5.456789 192.168.0.10 -> 192.200.0.105 TCP 66 50000 -> 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
16  5.498765 192.200.0.105 -> 192.168.0.10 TCP 66 443 -> 50000 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
17  5.499012 192.168.0.10 -> 192.200.0.105 TCP 54 50000 -> 443 [ACK] Seq=1 Ack=1 

[#13]

@timsansom so are we now saying that the MAC works but the debian box doesn't ? that's different to before..

If its just the debian box, then that's where the problem is. 

On the outgoing ICMP packets , what's the destination mac address ? 

The correct mac address should be that of the router i.e the packet needs routing via the default gateway. It looks like the debian box thinks 192.200... is on the local network and the packet doesnt need to be routed, so it tries sending directly to what it thinks is 192.200.0.101

[#14]

Moderator's note:
Thread moved from Full Fibre to Everything Else 

[#15]

@MisterW 

maybe I'm having a bad morning, but I'm unsure what this is for if it's on the router

there is also a static route address set up to:

192.168.200.0

255.255.255.0

192.168.0.3

LAN

Wireguard-Docker

Assuming the destination is 192.168.200.0 with the gateway being 192.168.0.3 

Why would any route be needed, wouldn't the default gateway set on the debian device be all that's needed.