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

Seems like UDP hole punching is not working or something else #112

New Issue
Closed
opened 2025-11-20 05:06:29 -05:00 by saavagebueno · 3 comments
saavagebueno commented 2025-11-20 05:06:29 -05:00
Owner
Copy Link

Originally created by @shrisha108 on GitHub (Feb 11, 2022).

Hello,
I just registered with official Wiretrustee website to try this service and added two machines, Fedora 35 and Ubuntu 20.04. In a dashboard I can see that both peers are online but when I'm trying to ping them nether of them can reach each other. What could be a problem? Some ports should be open? Setup seems quite straight forward. Log not showing any errors.
Any help would be appreciated.
Regards.

Originally created by @shrisha108 on GitHub (Feb 11, 2022). Hello, I just registered with official Wiretrustee website to try this service and added two machines, Fedora 35 and Ubuntu 20.04. In a dashboard I can see that both peers are online but when I'm trying to ping them nether of them can reach each other. What could be a problem? Some ports should be open? Setup seems quite straight forward. Log not showing any errors. Any help would be appreciated. Regards.
saavagebueno commented 2025-11-20 05:06:30 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Feb 11, 2022):

Hello @shrisha108 , sorry to hear that you are facing such issues with Wiretrustee and I would like to help you on this issue.

To answer your question, in many default cases, they should be able to communicate directly without further configuration required. Also, currently, our connection status in the dashboard reflects only management to peer status and not peer-to-peer connections, with that in mind, can you check a couple of things to help us understand better your case?

1 - Is there any restricted firewall rules in either node?
2 - check for connection status in our client logs:

sudo grep 'opened a connection to peer' /var/log/wiretrustee/client.log

3 - if that doesn't return any logs, you can send us the warn and error logs:

sudo grep -E 'warn|error'  /var/log/wiretrustee/client.log

Also, I would be happy to follow up on our community Slack Workspace

@mlsmaycon commented on GitHub (Feb 11, 2022): Hello @shrisha108 , sorry to hear that you are facing such issues with Wiretrustee and I would like to help you on this issue. To answer your question, in many default cases, they should be able to communicate directly without further configuration required. Also, currently, our connection status in the dashboard reflects only management to peer status and not peer-to-peer connections, with that in mind, can you check a couple of things to help us understand better your case? 1 - Is there any restricted firewall rules in either node? 2 - check for connection status in our client logs: ```shell sudo grep 'opened a connection to peer' /var/log/wiretrustee/client.log ``` 3 - if that doesn't return any logs, you can send us the warn and error logs: ```shell sudo grep -E 'warn|error' /var/log/wiretrustee/client.log ``` Also, I would be happy to follow up on our community [Slack Workspace](https://join.slack.com/t/wiretrustee/shared_invite/zt-vrahf41g-ik1v7fV8du6t0RwxSrJ96A)
saavagebueno commented 2025-11-20 05:06:30 -05:00
Author
Owner
Copy Link

@shrisha108 commented on GitHub (Feb 11, 2022):

Hello @mlsmaycon Thank you for your answer. Should I just send you a direct message on Slack Workspace?

@shrisha108 commented on GitHub (Feb 11, 2022): Hello @mlsmaycon Thank you for your answer. Should I just send you a direct message on Slack Workspace?
saavagebueno commented 2025-11-20 05:06:30 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Feb 11, 2022):

Thanks, @shrisha108, for your time in our troubleshooting chat.

Just documenting our findings. The issue was caused by existing Iptables rules that were dropping packets from the CGNAT used by Wiretrustee.

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ts-input   all  --  0.0.0.0/0            0.0.0.0/0 
....
.....
Chain ts-input (1 references)
target     prot opt source               destination         
ACCEPT     all  --  100.125.145.17       0.0.0.0/0           
RETURN     all  --  100.115.92.0/23      0.0.0.0/0           
DROP       all  --  100.64.0.0/10        0.0.0.0/0

executing the command below solved the issue:

sudo iptables -I  ts-input  1 -s 100.64.0.0/24 -j ACCEPT

As we discussed, I will follow up on the Oracle cloud investigation on the ticket #228

@mlsmaycon commented on GitHub (Feb 11, 2022): Thanks, @shrisha108, for your time in our troubleshooting chat. Just documenting our findings. The issue was caused by existing Iptables rules that were dropping packets from the CGNAT used by Wiretrustee. ```shell Chain INPUT (policy ACCEPT) target prot opt source destination ts-input all -- 0.0.0.0/0 0.0.0.0/0 .... ..... Chain ts-input (1 references) target prot opt source destination ACCEPT all -- 100.125.145.17 0.0.0.0/0 RETURN all -- 100.115.92.0/23 0.0.0.0/0 DROP all -- 100.64.0.0/10 0.0.0.0/0 ``` executing the command below solved the issue: ```shell sudo iptables -I ts-input 1 -s 100.64.0.0/24 -j ACCEPT ``` As we discussed, I will follow up on the Oracle cloud investigation on the ticket #228
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#112
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?