Unable to use telepresence at home

[pitming]

Describe the problem
I am using telepresence at my office and it runs perfectly fine.
However, when I'm home the DNS part of it doesn't work.
So I can:

• connect to the cluster
• Make an intercept/ingest
• volume is mounted

but DNS resolve doesn't work.
I suspect something between VPN, Firewall, ... But I am not an expert and doesn't now where to start to search or give indication to the IT guys

in the daemon logs, I see:
2025-04-11 11:18:25.5035 info daemon/session : -- Starting new session
2025-04-11 11:18:26.0130 info daemon/session : Connected to OSS Traffic Manager v2.22.2
2025-04-11 11:18:26.0130 info daemon/session : Connected to Manager 2.22.2
2025-04-11 11:18:26.0130 info daemon/session : also-proxy subnets [10.42.0.0/16]
2025-04-11 11:18:26.0130 info daemon/session : never-proxy subnets [10.129.76.136/32]
2025-04-11 11:18:26.0130 info daemon/session : allow-conflicting subnets []
2025-04-11 11:18:26.0130 info daemon/session : Configuration reloaded
2025-04-11 11:18:26.1078 info daemon/session/network : also-proxy subnets [10.42.0.0/16]
2025-04-11 11:18:26.1078 info daemon/session/network : never-proxy subnets [10.129.76.136/32]
2025-04-11 11:18:26.1078 info daemon/session/network : allow-conflicting subnets []
2025-04-11 11:18:29.1086 warning daemon/session/network : Manager IP 10.42.0.131 is connectable but not a traffic-manager instance (rpc error: code = DeadlineExceeded desc = context deadline exceeded while waiting for connections to become ready). Will proxy pods, but this may interfere with your VPN routes.
2025-04-11 11:18:32.1096 info daemon/session/network : Adding service subnet 10.43.0.0/16
2025-04-11 11:18:32.1096 info daemon/session/network : Adding pod subnet 10.42.0.0/24
2025-04-11 11:18:32.1200 info daemon/session/network : Creating interface tel0
2025-04-11 11:18:32.1940 info stdlog : Using existing driver 0.14
2025-04-11 11:18:32.2038 info stdlog : Creating adapter
2025-04-11 11:18:32.4448 info daemon/session/network : Setting cluster DNS to 10.42.0.131
2025-04-11 11:18:32.4448 info daemon/session/network : Setting cluster domain to "cluster.local."
2025-04-11 11:18:32.4448 info daemon/session/network : Dropping never-proxy "10.129.76.136/32" because it is not routed
2025-04-11 11:18:32.4601 info daemon/session/network : Starting Endpoint
2025-04-11 11:18:35.3486 info daemon/session/dns : Using fallback DNS server: 10.250.34.1

I also try to see if those DNS would work but without success
nslookup {myService}.{myNamespace}.svc.cluster.local 10.42.0.131 --> UNKNOWN
nslookup {myService}.{myNamespace}.svc.cluster.local 10.250.34.1 --> UNKNOWN

So, I confess I'm a little stuck here and don't really now where I should continue my investigation.

Can someone help ?

[pitming]

here is the result of tp status (that looks quite good to me)
OSS User Daemon: Running
Version : 2.22.2
Executable : C:\telepresence\telepresence.exe
Install ID : 57db3ed4-20fe-4eb9-8e34-5ab8e7336909
Status : Connected
Kubernetes server : https://10.129.76.136:6443
Kubernetes context: myContext
Namespace : myNamespace
Manager namespace : ambassador
Mapped namespaces : [ambassador cert-manager custom-agents default elastic-system external-services myNamespace kruise-daemon-config kruise-system kube-public metallb-system monitoring openkruise strimzi-kafka-operator]
OSS Root Daemon: Running
Version: v2.22.2
DNS :
Local IP : 127.0.0.1
Remote IP : 10.42.0.131
Exclude suffixes: [.com .io .net .org .ru]
Include suffixes: []
Timeout : 4s
Subnets: (2 subnets)
- 10.43.0.0/16
- 10.42.0.0/24
OSS Traffic Manager: Connected
Version : v2.22.2
Traffic Agent: ghcr.io/telepresenceio/tel2:2.22.2

[thallgren]

The 2.22.3 version contains a fix for DNS that might help. It affects the situation when you're using single label names and have no traffic-agents installed.

Using debug logging is always favorable when dealing with issues like this. The daemon.log will then show what it actually does with your lookup attempts. The logs of the traffic-manager pod might also shed some light.

[pitming]

Thx for your quick answer.
I did install 2.22.3 but still have the same problem.
Also activate debug logs in config.yml

logLevels:
  userDaemon: debug
  rootDaemon: debug

Should I see something being added in the log when I curl {myService} ?

I don't see any obvious problems in the logs

[thallgren]

Yes, you should see something in the log when you curl a service. If you don't, then your Windows DNS system isn't sending the lookup to the Telepresence DNS resolver.