Egress Gateway (beta)


This is a beta feature. Please provide feedback and file a GitHub issue if you experience any problems.


Egress Gateway requires a 5.2 or more recent kernel.

The egress gateway allows users to redirect egress pod traffic through specific, gateway nodes. Packets are masqueraded to the gateway node IP.

This document explains how to enable the egress gateway and configure egress NAT policies to route and SNAT the egress traffic for a specific workload.


This guide assumes that Cilium has been correctly installed in your Kubernetes cluster. Please see Quick Installation for more information. If unsure, run cilium status and validate that Cilium is up and running.

Enable Egress Gateway

The feature is disabled by default. The egress gateway requires BPF masquerading, which itself requires BPF NodePort to be enabled. An easy way to enable all requirements is as follows.

If you installed Cilium via helm install, you may enable the Egress gateway feature with the following command:

helm upgrade cilium cilium/cilium --version 1.11.5 \
   --namespace kube-system \
   --reuse-values \
   --set egressGateway.enabled=true \
   --set bpf.masquerade=true \
   --set kubeProxyReplacement=strict

Egress Gateway support can be enabled by setting the following options in the cilium-config ConfigMap:

enable-ipv4-egress-gateway: true
enable-bpf-masquerade: true
kube-proxy-replacement: strict

Create an External Service (Optional)

This feature will change the default behavior how a packet leaves a cluster. As a result, from the external service’s point of view, it will see different source IP address from the cluster. If you don’t have an external service to experiment with, nginx is a very simple example that can demonstrate the functionality, while nginx’s access log shows which IP address the request is coming from.

Create an nginx service on a Linux node that is external to the existing Kubernetes cluster, and use it as the destination of the egress traffic.

$ # Install and start nginx
$ sudo apt install nginx
$ sudo systemctl start nginx

$ # Make sure the service is started and listens on port :80
$ sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2021-04-04 21:58:57 UTC; 1min 3s ago
$ curl  # Assume is the external IP of the node
<title>Welcome to nginx!</title>

Create Client Pods

Deploy a client pod that will generate traffic which will be redirected based on the configurations specified in the CiliumEgressNATPolicy.

$ kubectl create -f
$ kubectl get po
NAME                             READY   STATUS    RESTARTS   AGE
pod/mediabot                     1/1     Running   0          14s

$ kubectl exec mediabot -- curl
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">

Verify access log from nginx node or other external services that the request is coming from one of the node in Kubernetes cluster. For example, in nginx node, the access log will contain something like the following:

$ tail /var/log/nginx/access.log
[...] - - [04/Apr/2021:22:06:57 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.52.1"

In the previous example, the client pod is running on the node, so the result makes sense. This is the default Kubernetes behavior without egress NAT.

Configure Egress IPs

Deploy the following deployment to assign additional egress IP to the gateway node. The node that runs the pod will have additional IP addresses configured on the external interface (enp0s8 as in the example), and become the egress gateway. In the following example, and becomes the egress IP which can be consumed by Egress NAT Policy. Please make sure these IP addresses are routable on the interface they are assigned to, otherwise the return traffic won’t be able to route back.

apiVersion: apps/v1
kind: Deployment
  name: "egress-ip-assign"
    name: "egress-ip-assign"
  replicas: 1
      name: "egress-ip-assign"
        name: "egress-ip-assign"
        # the following pod affinity ensures that the "egress-ip-assign" pod
        # runs on the same node as the mediabot pod
            - labelSelector:
                  - key: class
                    operator: In
                      - mediabot
                  - key: org
                    operator: In
                      - empire
              topologyKey: ""
      hostNetwork: true
      - name: egress-ip
        command: ["/bin/sh","-c"]
          privileged: true
        - name: EGRESS_IPS
          value: ""
        - "for i in $EGRESS_IPS; do ip address add $i dev enp0s8; done; sleep 10000000"
              - "/bin/sh"
              - "-c"
              - "for i in $EGRESS_IPS; do ip address del $i dev enp0s8; done"

Create Egress NAT Policy

Apply the following Egress NAT Policy, which basically means: when the pod is running in the namespace default and the pod itself has label org: empire and class: mediabot, if it’s trying to talk to IP CIDR, then use egress IP In this example, it tells Cilium to forward the packet from client pod to the gateway node with egress IP, and masquerade with that IP address.

kind: CiliumEgressNATPolicy
  name: egress-sample
  - podSelector:
        org: empire
        class: mediabot
        # The following label selects default namespace
        io.kubernetes.pod.namespace: default
    # Or use namespace label selector to select multiple namespaces
    # namespaceSelector:
    #  matchLabels:
    #    ns: default
  egressSourceIP: ""

Let’s switch back to the client pod and verify it works.

$ kubectl exec mediabot -- curl
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">

Verify access log from nginx node or service of your chose that the request is coming from egress IP now instead of one of the nodes in Kubernetes cluster. In the nginx’s case, you will see logs like the following shows that the request is coming from now, instead of

$ tail /var/log/nginx/access.log
[...] - - [04/Apr/2021:22:06:57 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.52.1"