Plans to implement Funnel?

[julianfairfax]

Feature request

Are there plans to implement support for tailscale's Funnel?

I can't actually use headscale, as the whole reason I'm using tailscale is that I can't do port forwarding, and thus, my running head scale server would be unreachable by all devices.

Using tailscale though, I find the Funnel useful, as I run a Nextcloud server, and want to share links to my files with people not on my tailnet.

It would thus be cool to have this feature in headscale, for those who can use it!

[kradalby]

We cannot really implement Tailscale's Funnel per se as it is not a public infrastructure like DERP. The way it works is roughly by setting up a connection between your node and the Tailscale Funnel ingress via your tailnet. This means that the tailnet must be hosted on tailscale.com.

In theory we could run our own "Headscale Funnel" infrastructure, but we have no capacity to do that.

or empower users to set this up themselves, but that still requires you to have a server with a public IP etc. For the record, this can already be done with a couple of lines of config and https://github.com/samhocevar/rinetd.

[nikicat]

If I understand correctly one of the main Funnel features is the automatic mapping of a subdomain to an exposed service with automatic certificate issuing (using letsencrypt for user-provided domain). I would certainly use such a feature if Headscale implemented it.

[rallisf1]

I guess it could be implemented via 3rd party services like ngrok. My favorite is cloudflare tunnel. It is free, cloudflared is open source and all you really need is a domain on cloudflare.

[nikicat]

Yes, I want something like you mentioned @rallisf1 , but hosted on my own server, not a third-party service, that's why I'm actually using headscale instead of tailscale.

[rallisf1]

Yes, I want something like you mentioned @rallisf1 , but hosted on my own server, not a third-party service, that's why I'm actually using headscale instead of tailscale.

This would require a reverse proxy and a dns server. Reverse proxy is easy, I already run headscale behind caddy. You'd need some form of integration with headscale though to generate the config for the Funnels. The DNS server must be public facing, be set as the designated nameserver for the domain you own (different than the magicDNS domain) and also integrated with headscale. Most registrars require at least 2 nameservers though, plus it's hell of a lot easier to just use a 3rd party DNS service that provides an API, like cloudflare...

[nikicat]

Reverse proxy, dns server, and a certificate manager (for https support) - all this should ideally be integrated into a single application. btw, the domain used for forwarding could be a 2nd level domain (or even deeper) so it should not be a problem to have only one NS for that.

[rallisf1]

Reverse proxy, dns server, and a certificate manager (for https support) - all this should ideally be integrated into a single application.

I am strongly against this. There are battle tested open source packages that will do a better job than any 1st party implementation, plus I bet there is no capacity to even consider that. Integration, docs and a docker-compose.yml for the lazy is all that it takes.

btw, the domain used for forwarding could be a 2nd level domain (or even deeper) so it should not be a problem to have only one NS for that.

true but that means exposing your internal domains to the internet and frankly I'd never do that, even when they point to 100.x.x.x IPs.

[nikicat]

I just partially understand and accept your opinion - using proven tools is a good way, but nevertheless, we need a manager program that will

1. accept and store requests for exposing internal services
2. create subdomain records in the dns server
3. create a config section in the reverse proxy configuration
4. issue a new certificate for the subdomain created
5. monitor and keep updated all this stuff

It doesn't look like a trivial thing from my point of view.

[renne]

I suggest to run Tailscale exit nodes on servers with public static IP-adresses.

For Funnel requests Headscale just needs to push the necessary DNAT rules for opening and forwarding ports to the Tailscale exit node.

Lego can be used by Headscale to configure the primary DNS-server of your domain provider.

That way one only needs to rent a small VPS (1 vCPU, 512 MB RAM, 1 GB storage) to run an "Funnel" gateway.

For security reasons I suggest to run the TLS-server on your application servers instead of the Tailscale exit node (in my opinion the Tailscale exit node is not a secure host because the server provider has access).

[hoijui]

I am also interested in this feature. While I am an IT person, I only have very basic networking knowledge (mostly just IPv4 basics). We have a tech-related non-profit (NPO) - promoting/pushing Open Source Hardware - which rents a (virtual) server. Personally I have a low-power-consumption mini server at home, behind a CGNAT. I need it to be publicly reachable, providing web-serving, SSH server, email-server and things like that, at some point. Most importantly though, I want to use it for "hosting" distributed services nodes, like Tor, IPFS and such. This same setup should then be used by others that are part of the NPO. It would be nice to be able to host Headscale ourselfs, and allow all our members (for now me, for testing) to have their own public server at home, providing both fail-safety and backups within the organization in a distributed manner, as well as (probably most important) build consciousness amongst the members for what distributed means, what the benefits are, that it is possible to some extend already, and what is missing.

I understand maybe 50% of the conversation in this issue. I personally would like to have a section somewhere in the docu of Headscale, that deals with this topic, explaining that the exact feature "funnel" as it is in Tailscale does not exist, but ... "you can build something similar in different ways, for example ...". What do you think? I'd be happy to dummy-test such a section.

[rallisf1]

@hoijui it's not so much a technical problem as an economic one. For Funnels to work you either need a server with a public IP (2 of them if you want to host your own private nameservers) or 3rd party services (DNS + Proxy). Let's say you want to self-host everything. Although running a DNS and proxy is dirt cheap on resources, traffic is not and that's gonna be double than a normal web/application server because of tunelling remote connections. Economically it makes more sense to just host the damn thing you need in a VPS altogether and skip the VPN.

Tailscale (meaning the SaaS) makes money and can afford this service, most of us cannot.

Should there be a guide about it for those who don't care about the cost? Sure, but there are a gazzilion ways to accomplish this, thus there will still be people who want help with e.g. Apache and GoDaddy instead of Caddy and Cloudflare, and it will still not be an integration.

[hoijui]

I understand that it is an economical problem, and thus Headscale can not provide it for its community. My NPO though, could provide it for its members, as we are a small community, and people accessing our servers would also be fairly limited, meaning: in total, I could imagine it would not be a huge load on our server(s), to establish the incoming connections for our NATed server from our hosted server with the static IP. If you say it is not possible/makes no sense to document how to do it anyway, because too complex/too many options, then.. well.. it is so. :-)

[skedastically]

I propose an example "funnel" with my own stack (archive.org link), using Tailscale nodes and a TCP proxy to route traffic from a VPS towards a HTTPS reverse proxy on a Pi behind NAT. Traefik is said reverse proxy in both cases.

I also set the Pi to use the VPS as an exit node, so outgoing requests can also come from the VPS itself and not from my residential IP.

With the right DNS records and routings, this should allow you to host webservices. Automating this stack to spin up any service from any node in the tailnet is a harder story though... I'm not sure its aptness for the TOR/IPFS use case as @hoijui mentioned. Feel free to contact me for more discussions

[hoijui]

ehh cool, thank you for the article, @skedastically !

[qm3ster]

@skedastically FYI link times out for me right now.