Error "loading the rules" after reboot
-
I had to restore a backup after I lost some hardware -- I thnk this might be where the issue came from
I think this might be the first reboot that has occurred after the setupHere's the error:
18:15:59 There were error(s) loading the rules: /tmp/rules.debug:95: macro 'TAILSCALE__NETWORK' not defined - The line in question reads [95]: nat on $Tailscale inet from $OPT1__NETWORK to $TAILSCALE__NETWORK -> (Tailscale) static-portBut screenshots on my NAT page don't show the culprit.
Was able to get to the file /tmp/rules.debug but wasnt sure how to or even if I could edit the file
As noted in the sceenshot I don't even have and "static ports" defined in the settings BUT I think I might have in my prior setup for restoring a backup (I had to manually recreate a number of things to get the restored backup to work)
Just woud like to fix so that I quit getting the notification of the error
-
It's almost certainly because at the first boot it had not yet installed the Tailscale package when it first loaded the ruleset.
If that error doesn't re-appear after clearing it and the tailscale package is now installed then it's nothing to worry about.
-
So the error keeps recurring
Any way to get rid of whatever rule is trying to be laoded (probably form the backup)??Notifications in this message: 1
20:05:32 There were error(s) loading the rules: /tmp/rules.debug:95: macro 'TAILSCALE__NETWORK' not defined - The line in question reads [95]: nat on $Tailscale inet from $OPT1__NETWORK to $TAILSCALE__NETWORK -> (Tailscale) static-port
-
Do you not have Tailscale installed?
Do you have the tailscale interface assigned? You should not if you do.
-
I do have Tailscale installed
And I do assign the Tailscale assigned as an interface
The purpose is for it to assigned as a gateway for a static route for one of my external networks
(Basically utilizing Tailscale as a site to site for that particular external network)It has worked well for quite some time
The error based on the naming appears to be hold over from the prior backup though
-
Mmm the tailscale interface should not be assigned. Usually doing that causes boot to fail because the interface doesn't exist when the interface-check runs. I'm not sure how that isn't happening here but that rules error is likely caused by the same thing. In tailscale all the routing is expected to be handled by tailscale itself.
-
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.
-
Hmm, I'm not sure why you would need NAT there if each site is advertising the correct subnets. But yes that would be a problem if you needed to do it. In pfSense you need to assign an interface to apply NAT on it.
