Shadow

I pasted a specific screenshot elsewhere in this thread showing how to filter on just requests with a range header

Turns out cloudflare was responsible for breaking the 206 range requests for lemmy.ca, and probably quite a few of these other broken sites too.

Here’s how to fix with a caching rule:

The tailscale client should have created an interface, but I’ve never used it on a box also running wg. You don’t have a tailscale specific interface in ip addr show at all? That’s… odd.

Do you have a device at /dev/net/tun?

How do I do this?

Run ip route show table all

I would expect to see a line like:

192.168.178.0/24 dev tailscale0 table 52

Out of curiosity on a remote node do tcpdump -i tailscale0 -n icmp and then do a ping from the other side, does tcpdump see the icmp packets come in?

Relay “ams” means you’re using tailscales DERP node in amsterdam, this is expected if you don’t have direct connectivity through your firewall. Since you opened the ports that’s unusual and worth looking into, but I’d worry about that after you get basic connectivity.

So to confirm your behavior, you can tailscale ping each other fine and tailscale ping to the internal network. You cannot however ping from the OS to the remote internal network?

Have you checked your routing tables to make sure the tailscale client added the route properly?

Also have you checked your firewall rules? If you’re using ipfw or something, try just turning off iptables briefly and see if that lets you ping through.

Can your nodes ping each other on the tailscale ips? Check tailscale status and make sure the nodes see each other listed there.

Try tailscale ping 1.2.3.4 with the internal IP addresses and see what message it gives you.

tailscale debug netmap is useful to make sure your clients are seeing the routes that headscale pushes.

That should be all that’s required. Are you using ACLs? If so you need to provide access to the subnet router as well as a rule to the IP behind it

Did you enable the route in the admin web ui?