[GH-ISSUE #2740] Can't run netbird relay inside of digital ocean DOKS within a VPC. Relay can't connect to the management domain. Curl connects to netbird management domain just fine #5941

Open
opened 2026-08-05 01:05:55 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @adrian-moisa on GitHub (Oct 15, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/2740

Describe the problem

I'm trying to install a relay in a digital ocean DOKS cluster. The cluster is hosted in a VPC. The goal is to use CoreDNS as a custom DNS inside of the VPN to route traffic to the relevant ports of the DOKS. Problem that I have now is that with current setup I have to point traffic from CoreDNS to a public loadbalancer.

My goal is to eliminate the public IP. I could not find how to setup a private load balancer in DO so therefore I tried the next trick: setting up a netbird relay as ClusterIp. Now maybe this is wrong as well but can't find enough info on the web. My hope was that using a relay as ClusterIp I'm able to maintain all the traffic inside of the VPN and VPC with no public IPs involved.

  • The k8s config I'm using.
  • I checked the secret, I am convinced it's fine.
  • Maybe the entire config is complete junk. I was trying hard to shape it with GPT and claude. They halucinate really hard on this one.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vpn-relay
  labels:
    app: vpn-relay
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vpn-relay
  template:
    metadata:
      labels:
        app: vpn-relay
    spec:
      containers:
      - name: vpn-relay
        image: netbirdio/netbird:latest
        ports:
          - containerPort: 51820
            protocol: UDP
        env:
          - name: NB_MANAGEMENT_URL
            value: "https://my-vpn-addr" # management domain, not relay
          - name: NB_RELAY
            value: "true"
          - name: NB_SETUP_KEY
            valueFrom:
              secretKeyRef:
                name: netbird-peer-key
                key: NETBIRD_KEY
          - name: NB_LOG_LEVEL
            value: "debug"
---
apiVersion: v1
kind: Service
metadata:
  name: vpn-relay
spec:
  selector:
    app: vpn-relay
  ports:
    - protocol: UDP
      port: 51820
      targetPort: 51820
  type: ClusterIP 

To Reproduce

  • Start the relay by applying the k8s yaml
  • Check status kubectl logs -l app=vpn-relay
    It will keep saying:
2024-10-15T09:50:37Z DEBG util/net/dialer_nonios.go:52: Dialing tcp my-vpn-addr:443
2024-10-15T09:50:40Z DEBG util/net/dialer_nonios.go:52: Dialing tcp my-vpn-addr:443
2024-10-15T09:50:45Z DEBG util/net/dialer_nonios.go:52: Dialing tcp my-vpn-addr:443
2024-10-15T09:50:52Z DEBG util/net/dialer_nonios.go:52: Dialing tcp my-vpn-addr:443
2024-10-15T09:51:03Z DEBG util/net/dialer_nonios.go:52: Dialing tcp my-vpn-addr:443
2024-10-15T09:51:05Z INFO util/grpc/dialer.go:75: DialContext error: context deadline exceeded
2024-10-15T09:51:05Z INFO management/client/grpc.go:56: createConnection error: context deadline exceeded
2024-10-15T09:51:05Z ERRO management/client/grpc.go:64: failed creating connection to Management Service: context deadline exceeded
2024-10-15T09:51:05Z ERRO client/internal/login.go:96: failed connecting to the Management service https://my-vpn-addr:443 context deadline exceeded
Error: foreground login failed: backoff cycle failed: context deadline exceeded

my-vpn-addr right now is the netbird management domain not the relay domain. Afaik, I need to use management one.

I tested access to the VPN via curl, Works just fine.
run test-curl --rm -it --image=curlimages/curl -- curl -v https://my-vpn-addr

Expected behavior

Should create a new peer and use the created key.

Are you using NetBird Cloud?

No, I'm using self hosted.

NetBird version

0.29.4

NetBird status -dA output:

Can't share, too sensitive. All I can say it works 100% ok with other peers (droplets with netbird client installed).

Do you face any (non-mobile) client issues?

Not afaik

Screenshots

Too sensitive

Additional context

-The entire cluster is supposed to be completely hidden by the VPN. So far I can hide the DNS. I wasn't able to start a relay. Maybe I'm completely misunderstanding the entire thing.

  • I was able to hide droplets in the VPN by installing the netbird client. I used private IP for DNS records. And I blocked everything with UFW. I could go one step further by placing the droplet in a VPC to hide it's IP, though I think I will end up in the same spot, something is publicly exposed.
  • Is the thing that I'm trying to do even making sense? My concern is that a public load balancer can be the target of DDOS attack and since the DNS is private I can't use Cloudflare to secure it.
  • I saw the Release Notes for v0.29.0 and I read about the new relay. But I have no clue how this could fit in my request. As I said prior, maybe my yaml makes no sense. I created it with gen AI, and could not find any useful samples on the web. So it's potentially complete garbage?
Originally created by @adrian-moisa on GitHub (Oct 15, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/2740 **Describe the problem** I'm trying to install a relay in a digital ocean DOKS cluster. The cluster is hosted in a VPC. The goal is to use CoreDNS as a custom DNS inside of the VPN to route traffic to the relevant ports of the DOKS. Problem that I have now is that with current setup I have to point traffic from CoreDNS to a public loadbalancer. My goal is to eliminate the public IP. I could not find how to setup a private load balancer in DO so therefore I tried the next trick: setting up a netbird relay as ClusterIp. Now maybe this is wrong as well but can't find enough info on the web. My hope was that using a relay as ClusterIp I'm able to maintain all the traffic inside of the VPN and VPC with no public IPs involved. - The k8s config I'm using. - I checked the secret, I am convinced it's fine. - Maybe the entire config is complete junk. I was trying hard to shape it with GPT and claude. They halucinate really hard on this one. ``` apiVersion: apps/v1 kind: Deployment metadata: name: vpn-relay labels: app: vpn-relay spec: replicas: 1 selector: matchLabels: app: vpn-relay template: metadata: labels: app: vpn-relay spec: containers: - name: vpn-relay image: netbirdio/netbird:latest ports: - containerPort: 51820 protocol: UDP env: - name: NB_MANAGEMENT_URL value: "https://my-vpn-addr" # management domain, not relay - name: NB_RELAY value: "true" - name: NB_SETUP_KEY valueFrom: secretKeyRef: name: netbird-peer-key key: NETBIRD_KEY - name: NB_LOG_LEVEL value: "debug" --- apiVersion: v1 kind: Service metadata: name: vpn-relay spec: selector: app: vpn-relay ports: - protocol: UDP port: 51820 targetPort: 51820 type: ClusterIP ``` **To Reproduce** - Start the relay by applying the k8s yaml - Check status `kubectl logs -l app=vpn-relay` It will keep saying: ```sh 2024-10-15T09:50:37Z DEBG util/net/dialer_nonios.go:52: Dialing tcp my-vpn-addr:443 2024-10-15T09:50:40Z DEBG util/net/dialer_nonios.go:52: Dialing tcp my-vpn-addr:443 2024-10-15T09:50:45Z DEBG util/net/dialer_nonios.go:52: Dialing tcp my-vpn-addr:443 2024-10-15T09:50:52Z DEBG util/net/dialer_nonios.go:52: Dialing tcp my-vpn-addr:443 2024-10-15T09:51:03Z DEBG util/net/dialer_nonios.go:52: Dialing tcp my-vpn-addr:443 2024-10-15T09:51:05Z INFO util/grpc/dialer.go:75: DialContext error: context deadline exceeded 2024-10-15T09:51:05Z INFO management/client/grpc.go:56: createConnection error: context deadline exceeded 2024-10-15T09:51:05Z ERRO management/client/grpc.go:64: failed creating connection to Management Service: context deadline exceeded 2024-10-15T09:51:05Z ERRO client/internal/login.go:96: failed connecting to the Management service https://my-vpn-addr:443 context deadline exceeded Error: foreground login failed: backoff cycle failed: context deadline exceeded ``` my-vpn-addr right now is the netbird management domain not the relay domain. Afaik, I need to use management one. I tested access to the VPN via curl, Works just fine. `run test-curl --rm -it --image=curlimages/curl -- curl -v https://my-vpn-addr` **Expected behavior** Should create a new peer and use the created key. **Are you using NetBird Cloud?** No, I'm using self hosted. **NetBird version** `0.29.4` **NetBird status -dA output:** Can't share, too sensitive. All I can say it works 100% ok with other peers (droplets with netbird client installed). **Do you face any (non-mobile) client issues?** Not afaik **Screenshots** Too sensitive **Additional context** -The entire cluster is supposed to be completely hidden by the VPN. So far I can hide the DNS. I wasn't able to start a relay. Maybe I'm completely misunderstanding the entire thing. - I was able to hide droplets in the VPN by installing the netbird client. I used private IP for DNS records. And I blocked everything with UFW. I could go one step further by placing the droplet in a VPC to hide it's IP, though I think I will end up in the same spot, something is publicly exposed. - Is the thing that I'm trying to do even making sense? My concern is that a public load balancer can be the target of DDOS attack and since the DNS is private I can't use Cloudflare to secure it. - I saw the Release Notes for v0.29.0 and I read about the new relay. But I have no clue how this could fit in my request. As I said prior, maybe my yaml makes no sense. I created it with gen AI, and could not find any useful samples on the web. So it's potentially complete garbage?
saavagebueno added the triage-needed label 2026-08-05 01:05:55 -04:00
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#5941