pfSense Tailscale VPN misbehaving when not Enabled

[ericreiss]

Hopefully this has not already been reported.

I looked and did not see any posts about this.

The other day I had a problem when I noticed that I could not connect to our office pfSense on a Netgate 6100 remotely using the Tailscale IP.

I connected to a computer behind the pfSense on our 10.1.3.0/24 subnet and connected to the Netgate 6100 LAN3 port which has IP address 10.1.3.1

I went to the pfSense UI and the VPN menu then in the Tailscale settings, unchecked the Enable Tailscale checkbox then hit the save button.

I then lost connection to the UI.

I expected that from a remote connection using the direct Tailscale IP of the pfSense device but not when connected using the local IP of 10.1.3.1.

I then realized I could not ping any of the other devices on the LAN3 subnet 10.1.3.0/24. See my attached picture of our simplified topology.

I could ping 10.1.2.11 on the LAN2 subnet 10.1.2.0/24.

Many of the devices on the 10.1.3.0/24 subnet have Tailscale on them and I could ping them using the Tailnet IP but not the real 10.1.3.0/24 IPs.

I asked someone in the office with access to the server room to reboot the Netgate 6100 without success. Then I had the person powercycle the switch that is on the LAN3 10.1.3.0/24 subnet, also without success.

Fortunately, I also had Wireguard VPN installed on the pfSense and connected to the UI with that then re-enabled the Tailscale VPN.

I was now able to ping devices across the 10.1.3.0/24 subnet as if nothing had ever happened.

I could also remotely get to the Tailnet IP of the pfSense which started this whole problem, not that it is important as part of this report.

My Tailscale version across most of the devices was a little behind and the pfSense was running version 1.56.1 with pfSense version 24.03-RELEASE.

I decided to try this again that night and reproduced the exact same result without the reboots of the two devices.

I have a setup at home that mirrors this environment except the pfSense
24.03-RELEASE was on Tailscale 1.74.1 and running on a PC.

I repeated the problem and the same thing happened.

I updated all my devices at home to Tailscale 1.76.6 and the pfSense to 1.76.6_1 then tried again. Same problem.

I did then update the office devices to 1.76.6 and the Netgate 6100 to 1.76.6_1.

Repeated the problem and had the same results as expected.

So it seems that when I turn off the Tailscale VPN on the pfSense device, I can't ping other devices on that subnet from a device on that subnet including the pfSense's port.

But I was able to ping the device 10.1.2.11 on the 10.1.2.0/24 subnet.

By pure accident, I noticed that in the Tailscale console under the pfSense device that the Subnets and Exit Node boxes where shown. See image.

I went into the Edit route settings and saw that I had left the 10.1.3.0/24 subnet as a subnet route and it was set to be used as an Exit Node.

In the pfSense Tailscale VPN settings I had two subnets advertised. See image.

So in the Tailscale console I unapproved the 10.1.30.0/24 subnet and saved it.

Then I repeated the whole test of disabling the Tailscale VPN on the pfSense.

Now I could ping across the 10.1.3.0 subnet.

So here is the problem which I think is a Bug. If you have advertised and approved subnets routes as Exit nodes and you disable Tailscale VPN on the pfSense then that subnet's devices can no longer contact one another (ping or otherwise) using their real IP addresses.

This does not sound like correct functionality.

I reproduced the successful and failing results when disabling the Tailscale VPN on two pfSense installations when subnet routes were not advertised as Exit nodes, versus having them advertised as exit nodes when diabling the firewall, respectively.