SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-08-04 19:55:09 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Signal service connection issue - incorrect port mapping in docker-compose.yml #2446

New Issue
Open
opened 2025-11-20 07:09:56 -05:00 by saavagebueno · 1 comment
saavagebueno commented 2025-11-20 07:09:56 -05:00
Owner
Copy Link

Originally created by @krth1k on GitHub (Nov 7, 2025).

Description

The NetBird client fails to connect to the Signal service when deployed using the official infrastructure_files setup with custom TLS certificates. The Signal service shows as "Disconnected" in netbird status, and clients experience timeout errors when attempting to connect.

Environment

  • NetBird Version: 0.59.12 (server), 0.59.11 (client)
  • Deployment Method: Docker Compose (infrastructure_files/artifacts)
  • TLS Configuration: Custom certificates (Let's Encrypt via dashboard container)
  • OS: Ubuntu 24.04 ARM64

Steps to Reproduce

  1. Deploy NetBird using the infrastructure_files setup
  2. Configure Signal service with custom TLS certificates
  3. Use the generated docker-compose.yml with port mapping 10000:80 for Signal service
  4. Connect a client using netbird up --management-url https://management.example.com:33073
  5. Check status with netbird status

Observed Behavior

  • Management server: Connected ✅
  • Signal server: Disconnected ❌
  • Port 10000 appears open but connections are refused/reset
  • Client logs show timeout errors during connection establishment

Server logs:

signal-1  | 2025-11-07T17:17:25Z INFO signal/cmd/run.go:150: running HTTPS server with WebSocket proxy: [::]:443
signal-1  | 2025-11-07T17:17:25Z INFO signal/cmd/run.go:161: running gRPC backward compatibility server: [::]:10000
signal-1  | 2025-11-07T17:17:25Z INFO signal/cmd/run.go:164: signal server version 0.59.12
signal-1  | 2025-11-07T17:17:25Z INFO signal/cmd/run.go:165: started Signal Service

Connection test:

$ nc -zv netbird.example.com 10000
nc: connect to netbird.example.com port 10000 (tcp) failed: Connection refused

Root Cause

The docker-compose.yml generated by the configure.sh script contains an incorrect port mapping for the Signal service:

signal:
  ports:
    - 10000:80  # INCORRECT - maps external 10000 to internal 80

However, the Signal service's logs clearly show it runs the gRPC backward compatibility server on internal port 10000, not port 80:

running gRPC backward compatibility server: [::]:10000

Solution

Change the port mapping to correctly expose the Signal service's internal port 10000:

signal:
  ports:
    - 10000:10000  # CORRECT - maps external 10000 to internal 10000

After applying this change and restarting the Signal container:

$ netbird status
Management: Connected
Signal: Connected ✅
Relays: 3/3 Available

Expected Behavior

The configure.sh script should generate the correct port mapping for the Signal service when using custom TLS certificates. The port mapping should be 10000:10000 to match the internal gRPC server port.

Additional Context

This issue occurs specifically when using the custom TLS certificate configuration (with --cert-file and --cert-key flags). The commented-out Let's Encrypt configuration may have different port requirements.

The docker-compose.yml configuration shows:

command: [
  "--cert-file", "/etc/letsencrypt/live/example.com/fullchain.pem",
  "--cert-key", "/etc/letsencrypt/live/example.com/privkey.pem",
  "--log-file", "console"
]

Suggested Fix

Update the infrastructure_files/configure.sh script to generate the correct port mapping for the Signal service:

ports:
  - 10000:10000

Or add documentation clarifying which port mapping should be used for different TLS configurations.

Originally created by @krth1k on GitHub (Nov 7, 2025). ## Description The NetBird client fails to connect to the Signal service when deployed using the official `infrastructure_files` setup with custom TLS certificates. The Signal service shows as "Disconnected" in `netbird status`, and clients experience timeout errors when attempting to connect. ## Environment - **NetBird Version**: 0.59.12 (server), 0.59.11 (client) - **Deployment Method**: Docker Compose (infrastructure_files/artifacts) - **TLS Configuration**: Custom certificates (Let's Encrypt via dashboard container) - **OS**: Ubuntu 24.04 ARM64 ## Steps to Reproduce 1. Deploy NetBird using the infrastructure_files setup 2. Configure Signal service with custom TLS certificates 3. Use the generated docker-compose.yml with port mapping `10000:80` for Signal service 4. Connect a client using `netbird up --management-url https://management.example.com:33073` 5. Check status with `netbird status` ## Observed Behavior - Management server: **Connected** ✅ - Signal server: **Disconnected** ❌ - Port 10000 appears open but connections are refused/reset - Client logs show timeout errors during connection establishment **Server logs:** ``` signal-1 | 2025-11-07T17:17:25Z INFO signal/cmd/run.go:150: running HTTPS server with WebSocket proxy: [::]:443 signal-1 | 2025-11-07T17:17:25Z INFO signal/cmd/run.go:161: running gRPC backward compatibility server: [::]:10000 signal-1 | 2025-11-07T17:17:25Z INFO signal/cmd/run.go:164: signal server version 0.59.12 signal-1 | 2025-11-07T17:17:25Z INFO signal/cmd/run.go:165: started Signal Service ``` **Connection test:** ```bash $ nc -zv netbird.example.com 10000 nc: connect to netbird.example.com port 10000 (tcp) failed: Connection refused ``` ## Root Cause The docker-compose.yml generated by the `configure.sh` script contains an incorrect port mapping for the Signal service: ```yaml signal: ports: - 10000:80 # INCORRECT - maps external 10000 to internal 80 ``` However, the Signal service's logs clearly show it runs the gRPC backward compatibility server on **internal port 10000**, not port 80: ``` running gRPC backward compatibility server: [::]:10000 ``` ## Solution Change the port mapping to correctly expose the Signal service's internal port 10000: ```yaml signal: ports: - 10000:10000 # CORRECT - maps external 10000 to internal 10000 ``` After applying this change and restarting the Signal container: ```bash $ netbird status Management: Connected Signal: Connected ✅ Relays: 3/3 Available ``` ## Expected Behavior The `configure.sh` script should generate the correct port mapping for the Signal service when using custom TLS certificates. The port mapping should be `10000:10000` to match the internal gRPC server port. ## Additional Context This issue occurs specifically when using the custom TLS certificate configuration (with `--cert-file` and `--cert-key` flags). The commented-out Let's Encrypt configuration may have different port requirements. The docker-compose.yml configuration shows: ```yaml command: [ "--cert-file", "/etc/letsencrypt/live/example.com/fullchain.pem", "--cert-key", "/etc/letsencrypt/live/example.com/privkey.pem", "--log-file", "console" ] ``` ## Suggested Fix Update the `infrastructure_files/configure.sh` script to generate the correct port mapping for the Signal service: ```yaml ports: - 10000:10000 ``` Or add documentation clarifying which port mapping should be used for different TLS configurations.
saavagebueno commented 2025-11-20 07:09:58 -05:00
Author
Owner
Copy Link

@prashant-prodigal commented on GitHub (Nov 13, 2025):

I faced the same issues, this solution fixed it. Thanks

@prashant-prodigal commented on GitHub (Nov 13, 2025): I faced the same issues, this solution fixed it. Thanks
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#2446
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?