Service names are not resolved with the correct ip address `Operation timed out`

[yildizbilal]

Describe the bug After connecting to the cluster with telepresence connect i tried to curl a service by its name but it didnt worked. A -vto the curl command gaves the information that a wrong IP address is resolved something with 127.x.x.x instead 10.x.x.x. A nslookup gives server can't find <service-name>: NXDOMAIN. But on a WSL it works, so that might be a macOS related issue.

I also deployed the echo-easy server to the default namespace, where curl echo-easy.default works properly. Needed services are in another namespace. Also we use istio for service mesh EXCEPT on the default namespace where curling the echo-easy server worked.

Intercepting a services works normally and i also use telepresence currently, but instead of using the names of the services i have to put the IP addresses when i want to request them to my environment. It would be easier when i can use the export environment feature of telepresence without modifying it.

Log Files I already sent them to @josecv

To Reproduce Steps to reproduce the behavior:

1. Connect to cluster: telepresence connect (connects properly)
2. Try to curl a service (not in the default namespace) where istio service mesh is configured.
3. When you put -v to the curl command you will see a 127.x.x.x IP address.
4. After a while you will get following error: curl: (7) Failed to connect to <service-name> port 3000: Operation timed out

Expected behavior The service should be able to resolved by its name and should response to the request properly.

Versions (please complete the following information):

• Output of telepresence version Client: v2.6.8 (api v3) Root Daemon: v2.6.8 (api v3) User Daemon: v2.6.8 (api v3)
• Operating system of workstation running telepresence commands macOS Catalina Version 10.15.7
• Kubernetes environment and Version [e.g. Minikube, bare metal, Google Kubernetes Engine] Azure Kubernetes Service with k8s v1.22.6

VPN-related bugs: Don't using VPN.

Additional context Things that i tried already:

• Reinstalling telepresence traffic-manager
• Intercepted a service so that the agent is installed and then tried to curl
• Using symbolic ports
• Using the full address: <service-name>.<namespace>.svc.cluster.local:3000