@stephenw10
Ok. Makes sense
I was advised by Tailscale support that I might need to establish NAT rules and a static route in pfsense if I wanted to force pfsense to use TS as a gateway for one of my other subnets on another one of my TS networks.
If I know the TS address of my local network is 100.xxx.xxx.xxx
Then how would you propose to establish that address as a gateway and then to use that address as a gateway for a static route for a subnet on an external 192.168.8.0/24 subnet (also on my TS network) ?
(Other than the error the routing is occurring properly now)
Here is communication from Tailscale support:
Kelly replied:
Hello,
I’m Kelly from the Tailscale support team. Thanks for reaching out! What you’re seeing is a known side effect of how Tailscale handles routing when subnet routing is enabled, especially on routers like pfSense and GL.iNet.
What’s happening is that Site B is advertising a subnet like 47.214.112.0/21, and that includes its own public IP (47.214.118.244). So when Site A tries to ping that public IP, Tailscale grabs the traffic and routes it through the tunnel instead of out the regular WAN unless you add a static route to force it out the normal way. That’s why disabling Tailscale or adding the route makes it work.
It’s just a side effect of advertising too broad of a subnet. Totally fixable by narrowing the subnet route or adding a static WAN route for that IP.
For the other issue of not being able to reach Site B’s LAN from Site A- I think this might be a NAT or routing issue:
Make sure both routers are advertising their LANs and the routes are actually enabled in the Tailscale admin console.
You might need outbound NAT rules on the routers to let traffic forward properly.
If you’ve disabled SNAT with --snat-subnet-routes=false, you likely need return routes for Tailscale’s 100.64.0.0/10 space, which a lot of home routers won’t handle. In that case, you can just use MASQUERADE/NAT on the router to make it work. (Related doc here )
For Linux-based routers (like GL.iNet), this usually fixes it:
iptables -A FORWARD -i tailscale0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tailscale0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Just keep in mind that’ll rewrite the source IP to the router itself, which might not be ideal depending on what you’re doing.
pfSense doesn’t support that SNAT flag (since it’s FreeBSD), so I think you have to rely on NAT/firewall rules or static routes to get things working cleanly.
Let me know your thoughts on this, and if this helped. I’m happy to answer any questions you may have.
