Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kubernetes operator: ingress proxies don't work in clusters with IPv6 Service IP range #12156

Closed
irbekrm opened this issue May 16, 2024 · 1 comment

Comments

@irbekrm
Copy link
Contributor

irbekrm commented May 16, 2024

What is the issue?

For the ingress proxies we set up iptables/nftables rules to forward traffic received on proxy's tailnet IP to the cluster backend Service's Cluster IP address.
A proxy gets assigned both a tailnet IPv4 and IPv6 tailnet addresses. We set the proxy forwarding rules for the IP address family of the backend Service only (see here).
This means that if the backend Service has an IPv6 address only the traffic received on proxy's IPv4 tailnet address is not being forwarded.

Steps to reproduce

  1. Set up a Kubernetes cluster with IPv6 address range for Services
  2. Expose a Service via tailscale load balancer class
  3. Retrieve the proxy's MagicDNS name and IPv4 and IPv6 address, in my example
 $kubectl get svc
NAME          TYPE           CLUSTER-IP             EXTERNAL-IP                                                    PORT(S)          AGE
kuard1        LoadBalancer   fdb9:b3b6:81ce::b391   fd7a:115c:a1e0::7501:7453,kuard1-9.<my-tailnet>.ts.net            80:30968/TCP     17h

  1. Exec the proxy Pod and observe that the firewall rules are only set up to forward traffic received on the IPv6 tailnet address of the proxy
$ iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination      
....
$ / # ip6tables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       all  --  anywhere             fd7a:115c:a1e0::7501:7453  to:fdb9:b3b6:81ce::b391
  1. Observe that trying to access the exposed cluster service via a curl from my machine to the tailnet service resolves to the IPv4 address of the proxy and does not succeed:
$ curl -vvv kuard1-9.tailbd97a.ts.net
*   Trying 100.120.116.83:80...
* connect to 100.120.116.83 port 80 failed: Connection refused
* Failed to connect to kuard1-9.tailbd97a.ts.net port 80 after 410 ms: Connection refused
* Closing connection 0
curl: (7) Failed to connect to kuard1-9.tailbd97a.ts.net port 80 after 410 ms: Connection refused
  1. Observe that the exposed service can be accessed over the IPv6 address of the proxy directly
$ curl -vvv [fd7a:115c:a1e0::7501:7453]
*   Trying fd7a:115c:a1e0::7501:7453:80...
* Connected to fd7a:115c:a1e0::7501:7453 (fd7a:115c:a1e0::7501:7453) port 80 (#0)
> GET / HTTP/1.1
> Host: [fd7a:115c:a1e0::7501:7453]
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
....

Are there any recent changes that introduced the issue?

No- this would affect operator ingress proxies at any Tailscale version

irbekrm added a commit that referenced this issue May 16, 2024
…dress is being created for an IPv6 backend(s)

Updates #12156

Signed-off-by: Irbe Krumina <[email protected]>
irbekrm added a commit that referenced this issue May 16, 2024
…dress is being created for an IPv6 backend(s) (#12159)

Updates #12156

Signed-off-by: Irbe Krumina <[email protected]>
@irbekrm
Copy link
Contributor Author

irbekrm commented May 18, 2024

Workaround is now documented in https://tailscale.com/kb/1236/kubernetes-operator#ipv6-support

@irbekrm irbekrm closed this as completed May 18, 2024
Mmx233 pushed a commit to MultiMx/tailscale that referenced this issue May 20, 2024
…dress is being created for an IPv6 backend(s) (tailscale#12159)

Updates tailscale#12156

Signed-off-by: Irbe Krumina <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant