Is this possible with Tailscale?

keyser

I’m looking into using tailscale for a project, but before I start spending hours testing I thought I’d ask here if these thoughts are possible to implement with Tailscale on pfSense:

I want to install the tailscale package and let pfSense itself participate in the tailnet, but because it will happen at multiple sites (all with same internal LAN IP scope) I have no desire to advertise the LAN subnet.
I actually just want remote access to some HTTPS and RDP ressources behind the pfSense over the tailnet, so I was thinking:

1: Is it possible to have fx. HAproxy listen on the Tailnet IP interface and forward to internal servers?
2: Can I create firewall rules on the Tailnet Interface? As far as I can tell I’m not supposed to assign it to a pfSense interface, but will rules made on the tailscale group still apply as intended?
3: Is it possible to do NAT port forwards from the Tailnet IP interface to internal servers (when I’m not supposed to assign the interface)?

If port forwards is not possible, is there another workaround to proxy/forward TCP sessions from the Tailnet IP of the firewall to an internal server?

Thanks :-)

luckman212

@keyser good questions! I have Tailscale disabled right now on my 6100 while I wait to see if there will be any news on 16784, so I didn't get to try these yet.

But my initial thought is it would probably be preferred to use Tailscale's native Serve feature to provide ingress to your RDP servers from other tailnet-joined devices. This way you get the benefit of their granular ACLs, logging etc. Any reason not to go that route?

keyser

@luckman212 said in Is this possible with Tailscale?:

@keyser good questions! I have Tailscale disabled right now on my 6100 while I wait to see if there will be any news on 16784, so I didn't get to try these yet.

But my initial thought is it would probably be preferred to use Tailscale's native Serve feature to provide ingress to your RDP servers from other tailnet-joined devices. This way you get the benefit of their granular ACLs, logging etc. Any reason not to go that route?

Ideally I agree, but this is a special case in more than one sense.

1: The customer would much prefer NOT to have any access at all to anything behind the pfSense apart from the forwarded ports needed. Call it extra security from operator mistakes

2: There will be 10 sites+ participating in the tailnet, and all LAN subnets on these sites are the same 192.168.100.0/24 (not meant to be routed together), so advertising the subnet will not work on more than one site at the time (unless I come up with tricky masquerading which I won’t)