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

[PR #4763] fix: correct Signal service port mapping for custom TLS certificates #4393

New Issue
Open
opened 2025-11-20 08:08:18 -05:00 by saavagebueno · 0 comments
saavagebueno commented 2025-11-20 08:08:18 -05:00
Owner
Copy Link

Original Pull Request: https://github.com/netbirdio/netbird/pull/4763

State: open
Merged: No

Describe your changes

This PR fixes a critical port mapping issue in the Signal service configuration that prevents clients from connecting when using custom TLS certificates.

The Signal service with custom TLS certificates runs HTTPS/WebSocket on internal port 443, not port 80. The current docker-compose template incorrectly maps $NETBIRD_SIGNAL_PORT:80, causing connection failures.

Updated port mapping:

signal:
  ports:
    - $NETBIRD_SIGNAL_PORT:443  # Changed from :80 to :443

Impact:

  • ✅ Signal service connects successfully
  • ✅ Clients can establish full NetBird connectivity
  • ✅ Uses modern HTTPS/WebSocket approach (port 443)
  • ℹ️ Port 10000 is kept for backward compatibility only

Issue ticket number and link

Fixes #4762

Stack

Checklist

  • Is it a bug fix
  • Is a typo/documentation fix
  • Is a feature enhancement
  • It is a refactor
  • Created tests that fail without the change (if possible)

By submitting this pull request, you confirm that you have read and agree to the terms of the Contributor License Agreement.

Documentation

Select exactly one:

Additional Details

Problem Analysis

When the Signal service runs with custom TLS certificates (via --cert-file and --cert-key flags), it starts the HTTPS/WebSocket server on internal port 443, not port 80.

Evidence from Signal service logs:

signal-1  | INFO signal/cmd/run.go:180: running HTTPS server with WebSocket proxy: [::]:443
signal-1  | INFO signal/cmd/run.go:161: running gRPC backward compatibility server: [::]:10000

This mismatch causes:

  • ❌ Signal service shows as "Disconnected" in netbird status
  • ❌ Connection refused errors when clients attempt to connect
  • ❌ Client timeout errors: "daemon up failed: rpc error: code = DeadlineExceeded"
  • ✅ Management service connects successfully (only Signal fails)

Testing Results

Before the fix:

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

$ netbird status
Management: Connected
Signal: Disconnected ❌

After the fix (port 443):

$ netbird status
Management: Connected
Signal: Connected ✅
Relays: 3/3 Available
NetBird IP: 100.65.165.148/16

Configuration Context

This issue specifically affects deployments using:

  • Custom TLS certificates (Let's Encrypt via dashboard container or similar)
  • Signal service command with --cert-file and --cert-key flags
  • Docker Compose setup from infrastructure_files

The configuration in question:

signal:
  command: [
    "--cert-file", "$NETBIRD_MGMT_API_CERT_FILE",
    "--cert-key", "$NETBIRD_MGMT_API_CERT_KEY_FILE",
    "--log-file", "console"
  ]
  ports:
    - $NETBIRD_SIGNAL_PORT:443  # Now correctly maps to HTTPS/WebSocket port

Related Changes

This PR also updates:

  • GitHub workflow tests to verify port 443 mapping
  • Infrastructure documentation to reflect correct port requirements

Summary by CodeRabbit

  • Chores

    • Updated signal service host-to-container port mapping to use port 443.
    • Test expectations adjusted to validate the signal port is 443.

  • Documentation

    • Infrastructure README updated to list new TCP port requirements: 80, 443, 33073, 10000, 33080; UDP ports remain 3478 and 49152–65535.
**Original Pull Request:** https://github.com/netbirdio/netbird/pull/4763 **State:** open **Merged:** No --- ## Describe your changes This PR fixes a critical port mapping issue in the Signal service configuration that prevents clients from connecting when using custom TLS certificates. The Signal service with custom TLS certificates runs HTTPS/WebSocket on **internal port 443**, not port 80. The current docker-compose template incorrectly maps `$NETBIRD_SIGNAL_PORT:80`, causing connection failures. **Updated port mapping:** ```yaml signal: ports: - $NETBIRD_SIGNAL_PORT:443 # Changed from :80 to :443 ``` **Impact:** - ✅ Signal service connects successfully - ✅ Clients can establish full NetBird connectivity - ✅ Uses modern HTTPS/WebSocket approach (port 443) - ℹ️ Port 10000 is kept for backward compatibility only ## Issue ticket number and link Fixes #4762 ## Stack <!-- branch-stack --> ### Checklist - [x] Is it a bug fix - [x] Is a typo/documentation fix - [ ] Is a feature enhancement - [ ] It is a refactor - [ ] Created tests that fail without the change (if possible) > By submitting this pull request, you confirm that you have read and agree to the terms of the [Contributor License Agreement](https://github.com/netbirdio/netbird/blob/main/CONTRIBUTOR_LICENSE_AGREEMENT.md). ## Documentation Select exactly one: - [x] I added/updated documentation for this change [ https://github.com/netbirdio/netbird/pull/4763 ] - [ ] Documentation is **not needed** for this change --- ## Additional Details ### Problem Analysis When the Signal service runs with custom TLS certificates (via `--cert-file` and `--cert-key` flags), it starts the HTTPS/WebSocket server on **internal port 443**, not port 80. **Evidence from Signal service logs:** ``` signal-1 | INFO signal/cmd/run.go:180: running HTTPS server with WebSocket proxy: [::]:443 signal-1 | INFO signal/cmd/run.go:161: running gRPC backward compatibility server: [::]:10000 ``` This mismatch causes: - ❌ Signal service shows as "Disconnected" in `netbird status` - ❌ Connection refused errors when clients attempt to connect - ❌ Client timeout errors: "daemon up failed: rpc error: code = DeadlineExceeded" - ✅ Management service connects successfully (only Signal fails) ### Testing Results **Before the fix:** ```bash $ nc -zv netbird.example.com 10000 nc: connect to netbird.example.com port 10000 (tcp) failed: Connection refused $ netbird status Management: Connected Signal: Disconnected ❌ ``` **After the fix (port 443):** ```bash $ netbird status Management: Connected Signal: Connected ✅ Relays: 3/3 Available NetBird IP: 100.65.165.148/16 ``` ### Configuration Context This issue specifically affects deployments using: - Custom TLS certificates (Let's Encrypt via dashboard container or similar) - Signal service command with `--cert-file` and `--cert-key` flags - Docker Compose setup from `infrastructure_files` The configuration in question: ```yaml signal: command: [ "--cert-file", "$NETBIRD_MGMT_API_CERT_FILE", "--cert-key", "$NETBIRD_MGMT_API_CERT_KEY_FILE", "--log-file", "console" ] ports: - $NETBIRD_SIGNAL_PORT:443 # Now correctly maps to HTTPS/WebSocket port ``` ### Related Changes This PR also updates: - GitHub workflow tests to verify port 443 mapping - Infrastructure documentation to reflect correct port requirements --- <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated signal service host-to-container port mapping to use port 443. * Test expectations adjusted to validate the signal port is 443. * **Documentation** * Infrastructure README updated to list new TCP port requirements: 80, 443, 33073, 10000, 33080; UDP ports remain 3478 and 49152–65535. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
saavagebueno added the pull-request label 2025-11-20 08:08:18 -05:00
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 pull-request
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#4393
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?