How to fix connect: no route to host in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 205 views

Network packets cannot reach the destination host because network policies block traffic, IP forwarding is disabled on nodes, or pods are isolated by CNI configuration. Unlike connection refused, the packet never reaches the application. Fix by reviewing network policies, enabling IP forwarding, or configuring CNI correctly.

Quick fix

Fixes connect: no route to host

kubectl get networkpolicies -A
kubectl describe networkpolicy <name> -n <namespace>
  1. Check network policies are permissive
  2. Verify IP forwarding is enabled on nodes
  3. Check CNI plugin is running
  4. Verify pod CIDR ranges don't conflict
kubernetes — error
kubectl get networkpolicies -A
kubectl describe networkpolicy <name> -n <namespace>
connect: no route to host

What this error means

This error indicates the network cannot route packets to the destination. In Kubernetes, it commonly occurs when: network policies deny inter-pod traffic, nodes have IP forwarding disabled, pod CIDR ranges conflict, or the CNI plugin is misconfigured. The packets are dropped at the network layer before reaching the pod.

Typical symptoms

  • Connection hangs indefinitely, no "refused" message
  • Traffic stops at node boundary
  • Works within same node but not cross-node
  • Network policy exists with restrictive rules
  • IP forwarding disabled on nodes
  • Pod CIDR conflicts with host network

Common causes

  1. Network policy denying egress or ingress traffic
  2. IP forwarding disabled on nodes (echo 1 > /proc/sys/net/ipv4/ip_forward)
  3. Pod CIDR range conflicts with node network
  4. CNI plugin not properly initialized
  5. Firewall on host or cloud network blocking traffic
  6. Pod security policies restricting network access
  7. Cross-cluster networking not configured

How to fix "connect: no route to host"

1Check network policies are permissive

List all network policies:

bash
kubectl get networkpolicies -A
kubectl describe networkpolicy <name> -n <namespace>

Network policies default to DENY if namespace is in deny-all mode. To allow all traffic:

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - {}
  egress:
  - {}
2Verify IP forwarding is enabled on nodes

SSH to node and check IP forwarding:

bash
sudo sysctl net.ipv4.ip_forward
# Should return: net.ipv4.ip_forward = 1

If 0, enable it:

bash
sudo sysctl -w net.ipv4.ip_forward=1
# Make persistent:
sudo echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sudo sysctl -p
3Check CNI plugin is running

Verify CNI pods are running on all nodes:

bash
kubectl get daemonset -n kube-system
kubectl get pods -n kube-system -o wide | grep -E "(weave|flannel|calico|cilium)"

Ensure DaemonSet has desired = current = ready count for all nodes. If not, check node taints and tolerations.

4Verify pod CIDR ranges don't conflict

Check cluster CIDR and node pod CIDR allocations:

bash
kubectl cluster-info dump | grep -i cidr
kubectl get nodes -o wide
# Check node allocatable IPs:
kubectl describe node <node-name> | grep -A2 "Allocated resources"

Ensure pod CIDR doesn't overlap with node network or other services.

5Test connectivity between nodes

SSH into one node and test reachability:

bash
ssh node1
ping <pod-ip-on-node2>
ping <service-ip>

If pings fail, the network layer has issues. Check iptables and routes on nodes.

6Check host firewall rules

On cloud platforms (AWS, Azure, GCP), check security groups:

bash
# AWS
aws ec2 describe-security-groups --query 'SecurityGroups[?GroupName=='default']'

# Azure
az network nsg list --query "[].{Name:name, ResourceGroup:resourceGroup}"

Ensure ingress/egress allow pod and service CIDR ranges.

7Use tcpdump to diagnose packet flow

Capture packets on source and destination nodes:

bash
sudo tcpdump -i any -nn src <pod-ip-1> or dst <pod-ip-1> -w capture.pcap
# Then analyze with Wireshark or tcpdump
sudo tcpdump -r capture.pcap

Look for packets arriving at destination node interface.

Advanced notes

This error is network-layer (layer 3), unlike "connection refused" which is application-layer. Cross-node communication is critical in Kubernetes; most CNI plugins (Flannel, Weave, Calico) handle routing automatically. In on-premises clusters, ensure all nodes are on same L2 network or routing is configured. For multus (multiple network interfaces), ensure routes are correct for secondary networks. Cilium offers advanced networking debugging: cilium connectivity test.

Frequently asked questions

What does "connect: no route to host" mean?
This error indicates the network cannot route packets to the destination. In Kubernetes, it commonly occurs when: network policies deny inter-pod traffic, nodes have IP forwarding disabled, pod CIDR ranges conflict, or the CNI plugin is misconfigured. The packets are dropped at the network layer before reaching the pod.
How do I fix "connect: no route to host"?
Network packets cannot reach the destination host because network policies block traffic, IP forwarding is disabled on nodes, or pods are isolated by CNI configuration. Unlike connection refused, the packet never reaches the application. Fix by reviewing network policies, enabling IP forwarding, or configuring CNI correctly.
What causes "connect: no route to host"?
Network policy denying egress or ingress traffic IP forwarding disabled on nodes (echo 1 > /proc/sys/net/ipv4/ip_forward) Pod CIDR range conflicts with node network
Is the "connect: no route to host" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading