I have a setup on microk8s with cilium and Metallb where I run a docker registry pod. The pod is assigned a service that gets an IP address from metallb and everything works fine if I run curl against the repository from a client in a different VLAN. When I try to curl from the node itself I can only access the registry on the internal IP.

For context, this cluster has 4 nodes living in a VLAN and there is a lot of supporting infrastructure where the different functionality lives in their own VLAN. All traffic between VLANs goes through a router/firewall.

The cluster nodes are multihomed, i.e. they get an IP address in every VLAN (native VLAN and several tagged VLANs). If I give the registry an external IP from the native VLAN of the node again it all works fine and I can reach the registry using the external IP.

What I find strange is that when I shoot the curl request to the external VLAN the router sees the destination as the internal IP of the pod. This is where I got completely lost.

Again the external IP can easily be used from clients running on machines in different VLANs just not from the nodes themselves, anybody can help with what I could be missing?

metallb is configured to use Layer2 advertising (ARP).

I can provide more detail if needed, though at this point I am not sure where to start. tcpdump on the node does not register any traffic, while on the router it shows the destination as the internal IP of the pod. The router then has no idea what to do with it.

Edit -> adding more context:

tcpdump from the router, when reaching the registry pod from a remote machine:

IP > Flags [.], ack 2048, win 1025, length 0

From the node:

IP > Flags [S], seq 490446341, win 64240, options [mss 1460,sackOK,TS val 898569173 ecr 0,nop,wscale 7], length 0

So somehow instead of trying to reach the, it tries to route to

The first IP is the IP of the service and an expected result, the other IP is the internal IP of the Pod, given out from the Cilium Cidr block (

Edit -> it also works if I do the call to the registry from the node, specifically using the nodes IP in the default VLAN:

curl --interface -k -X GET

However when specifying just running:

curl -k -X GET it uses the VLAN 12 IP as a source the problem occurs where the router sees the destination as (internal pod IP)

Edit -> tcpdump on the node:

tcpdump -i ens2.12 src and dst

gets traffic:

IP > Flags [S], seq 2235907990, win 64240, options [mss 1460,sackOK,TS val 907774853 ecr 0,nop,wscale 7], length 0

while doing the request:

curl --interface -k -X GET

Edit -> routing policy I have setup

        link: ens2
        id: 12
        dhcp4: false
            - to: default
              table: 12
            - from:
              table: 12

Thank you.

  • Are you using kube-proxy or Cilium's replacement?
    – pchaigno
    Commented Dec 10, 2023 at 11:36
  • Hi @pchaigno using kube-proxy in iptables mode.
    – Tomas
    Commented Dec 11, 2023 at 7:55
  • I see. Then AFAIK, kube-proxy should be in charge of externalIP service handling here, not Cilium. For the request that works, was it from a node inside the cluster or outside? If outside, did you try reaching the service from a remote node inside the cluster?
    – pchaigno
    Commented Dec 11, 2023 at 8:24
  • I tried all of the nodes. I double checked the routing table and can see the record I would expect: dev eth2.12 proto kernel scope link src The registry is on and the node ip (where I got this table from) is
    – Tomas
    Commented Dec 11, 2023 at 8:28
  • Funnily enough there is another machine on the default VLAN that is NOT a kubernetes node and from there I can reach the registry without any issue. It is not multihome, only lives on the default VLAN, so it hits the router and reaches the service IP
    – Tomas
    Commented Dec 11, 2023 at 8:33

1 Answer 1


In case you tried to reach the service IP from the docker registry Pod itself check: Edge case: A Pod fails to reach itself via the Service IP.

  • Thank you for the help, however I am trying to reach the registry pod from the node, not from the pod itself.
    – Tomas
    Commented Dec 11, 2023 at 7:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .