Funnel works only within tailnet #11849
Comments
kelivel
added
L2 Few
|
EDIT: This may have something to do with userspace networking. I setup a basic funnel for a directory using -- I was able to replicate this today due to an incoming support ticket (TSS-37882). I setup a basic version: "3.7"
services:
ts-dillinger-webserver:
image: tailscale/tailscale:latest
container_name: ts-dillinger
hostname: dillinger
environment:
- TS_AUTHKEY=tskey-client-kMq9ax11CNTRL-gGBoK58SWxnGj
- TS_EXTRA_ARGS=--advertise-tags=tag:container
- TS_SERVE_CONFIG=/config/dillinger.json
- TS_STATE_DIR=/var/lib/tailscale
volumes:
- /home/jimmy/.docker/data/ts-dillinger-webserver/state:/var/lib/tailscale
- /home/jimmy/.docker/data/ts-dillinger-webserver/config:/config
- /dev/net/tun:/dev/net/tun
cap_add:
- net_admin
- sys_module
restart: unless-stopped
ts-dillinger:
image: lscr.io/linuxserver/dillinger:latest
container_name: dillinger
environment:
- PUID=1000
- PGID=1000
- TZ=America/Chicago
volumes:
- /home/jimmy/.docker/data/dillinger/config:/config
network_mode: service:ts-dillinger-webserver
depends_on:
- ts-dillinger-webserver
restart: unless-stoppedIn my SERVE file I have: {
"TCP": {
"443": {
"HTTPS": true
}
},
"Web": {
"${TS_CERT_DOMAIN}:443": {
"Handlers": {
"/": {
"Proxy": "http://127.0.0.1:8080"
}
}
}
},
"AllowFunnel": {
"${TS_CERT_DOMAIN}:443": true
}
}I ran I see my container show up in my admin console, however I observed in the admin console, clicking on the machine to go to the machine page, under the TLS Configuration section the domain shows properly, but the Status shows as No certificate found. I observed that when trying to visit https://dillinger.taildfbdd.ts.net failed and I also couldn't resolve the hostname. I then swapped from a different tailnet I was on to the tailnet where I had deployed the container node and I tried bringing up https://dillinger.taildfbdd.ts.net. At this point I observed in the Docker container logs: so it seems clear that just trying to visit the service triggered a request for a TLS certificate. I had waited about 15 minutes before trying this as our documentation indicates it should happen in about 10 minutes but didn't for me. In summary, I experienced the same issue as described in the original post as well as is the customer who submitted a recent support ticket. Funnel is working more like Serve in that you cannot reach the funneled service if you're not connected to the tailnet where the funnel is running. |
|
|
|
I seem to have hit this again but when trying to expose a TCP port.
I ran an strace and it just sits there trying to connect: I can however connect to the endpoint if I am connected to the same tailnet as where the funnel is running: Of note, you can see it's using the Tailscale IP address of the device, and not the public IP address. |
|
i followed this video here from tailscale https://www.youtube.com/watch?v=tqvvZhGrciQ and this is my serve-config.json {
"TCP": {
"443": {
"HTTPS": true
}
},
"Web": {
"${TS_CERT_DOMAIN}:443": {
"Handlers": {
"/": {
"Proxy": "http://127.0.0.1:8123"
}
}
}
},
"AllowFunnel": {
"${TS_CERT_DOMAIN}:443": false
}
}im not even using the funnel yet and i get an error for acme request. |
|
For me the issue was that I had Weird, though, that everything seemed to be running along happy while fundamentally broken. |
|
I've followed the guide https://www.youtube.com/watch?v=tqvvZhGrciQ too, but I can't still reach the public exposed https service without being connected to tailnet (get a I have This is a part of my docker compose mealie:
image: ghcr.io/mealie-recipes/mealie:v1.9.0
container_name: mealie
restart: unless-stopped
network_mode: service:mealie-tailscale
deploy:
resources:
limits:
memory: 1000M
volumes:
- ./docker/mealie:/app/data/
environment:
ALLOW_SIGNUP: true
PUID: 1000
PGID: 1000
TZ: Europe/Rome
MAX_WORKERS: 1
WEB_CONCURRENCY: 1
BASE_URL: https://***.ts.net
depends_on:
- mealie-tailscale
mealie-tailscale:
image: tailscale/tailscale:latest
container_name: mealie-tailscale
hostname: mealie-tailscale
environment:
- TS_AUTHKEY=tskey-client-***?ephemeral=false
- "TS_EXTRA_ARGS=--advertise-tags=tag:container --reset"
- TS_SERVE_CONFIG=/config/mealie.json
- TS_STATE_DIR=/var/lib/tailscale
- TS_USERSPACE=false
volumes:
- ./docker/mealie-tailscale/state:/var/lib/tailscale
- ./docker/mealie-tailscale/config:/config
- /dev/net/tun:/dev/net/tun
cap_add:
- net_admin
- sys_module
restart: always
ports:
- 9001:9000And this is the config file content {
"TCP": {
"443": {
"HTTPS": true
}
},
"Web": {
"${TS_CERT_DOMAIN}:443": {
"Handlers": {
"/": {
"Proxy": "http://127.0.0.1:9000"
}
}
}
},
"AllowFunnel": {
"${TS_CERT_DOMAIN}:443": true
}
}
|
|
Can confirm the Mealie section in our Docker blog article isn't working due to the fact that you can't access the hostname which is generated. I've followed the article to a T again today and cannot access the Mealie instance while not being on the tailnet. From Bringing that URL up in Chrome fails with |
|
I also seem to be having the same issue where I can access the container-running funnels on other devices that are connected to my tailnet, but not from the internet. DNS lookups for my MagicDNS name fail, yet the "Machines" tab in my tailscale web admin console, and the command |
|
I spent several hours with this annoying me today, and I think I finally solved it for myself. I made lots of changes, but I think that there are 2 things that fully control outside access via funnel: In the documentation, there is a config.json file to set up funnel. The last blob is: "AllowFunnel": {
"${TS_CERT_DOMAIN}:443": false
}The key value should be true, not false. Secondly, ACLs control publishing funnel data to DNS. Without correct ACL setup, the DNS records will not be updated/set for the funnel, which is what is driving server not found errors - they're correct. In the ACL, we need to edit the nodeAttrs section to add permission for the tag used on containers to use funnel. In my case, I'm using the (very original) tag "nodeAttrs": [
{"target": ["tag:containers"], "attr": ["funnel"]}
],Hopefully that helps someone else down the road. |
|
Oh, wow, thank you @nkbooth, your second point did it for me. Here's my "nodeAttrs": [
{
- "target": ["autogroup:member"],
+ "target": ["autogroup:member", "tag:container"],
"attr": ["funnel"],
},
], |
|
Welp, I feel like a dummy! You're totally right @nkbooth! My |
|
Is it possible to get rid of the hassle of using/maintaining of a json config file, and enable funnel via command line args only, in your compose file or image build file? My AI friend thinks this will work (I doubt): Dockerfile: Docker compose: |
|
I am currently having the same issue with a Tailscale Funnel I just created on a Linux machine yesterday. I can access the funnel on my Mac which is on the same Tailnet, but only using the http address, e.g:
But the https full domain just results in a I have an identical Linux machine in my Tailnet located offsite where I am able to access the https funnel, as well as other machines. Edit: TS support got back to me, I had specified the wrong port when creating the tunnel. My mistake. |
Mine thankfully didn't take that long but it did take about 15 min to become active - your post was very helpful though in recognising that might be the issue, I was getting confused if I'd done something wrong as it was showing on the tailnet OK but not via the public internet. |
This is a soooo wicked parameter. |
Could you detail what you did wrong and what fixed it? |
What is the issue?
It seems to me that
funnelandservedo the same thing.Both allow me to serve content, which is then available via HTTPS only within my tailnet. As I understand,
funnelshould allow me to publish content publicly, on internet. However, my funneled resource works only when I'm connected to my tailnet.Steps to reproduce
podman run -d -p 8080:80 tutum/hello-worldtailscale funnel 8080Are there any recent changes that introduced the issue?
Nope, it never worked for me
OS
Linux, iOS
OS version
Fedora 39, iOS 17.4.1
Tailscale version
1.64.0
Other software
No response
Bug report
BUG-e75df7e9a917df61bd3b4c6244e8924e06db465d45115a81747489e4fae37b8c-20240423153805Z-00750e64e97bc4fe
The text was updated successfully, but these errors were encountered: