Troubleshooting & Workarounds

Method-specific limitations

For method-specific limitations see the documentation on the available proxying methods.

General limitations & workarounds

Docker containers

When using --method vpn-tcp or --method inject-tcp a container run via docker run will not inherit the outgoing functionality of the Telepresence shell. If you want to use Telepresence to proxy a containerized application you should use --method container.

localhost and the pod

localhost and will end up accessing the host machine—the machine where you run telepresencenot the pod. This can be a problem in cases where you are running multiple containers in a pod and you need your process to access a different container in the same pod.

The solution is to access the pod via its IP, rather than at You can have the pod IP configured as an environment variable $MY_POD_IP in the Deployment using the Kubernetes Downward API:

apiVersion: extensions/v1beta1
kind: Deployment
      - name: servicename
        image: datawire/telepresence-k8s:0.88
        - name: MY_POD_IP
              fieldPath: status.podIP


Amazon EC2 instances inside a VPC use a custom DNS setup that resolves internal names. This will prevent Telepresence from working properly. To resolve this issue, override the default name servers, e.g.,

sudo echo 'supersede domain-name-servers,;' >> /etc/dhcp/dhclient.conf
sudo dhclient

For more details see issue # 462.

Fedora 18+/CentOS 7+/RHEL 7+ and --docker-run

Fedora 18+/CentOS 7+/RHEL 7+ ship with firewalld enabled and running by default. In its default configuration this will drop traffic on unknown ports originating from Docker's default bridge network - usually

To resolve this issue, instruct firewalld to trust traffic from

sudo firewall-cmd --permanent --zone=trusted --add-source=
sudo firewall-cmd --reload

For more details see issue # 464.

results matching ""

    No results matching ""