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

[Bug] Networks function failure #1930

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

Originally created by @Cikaros on GitHub (May 31, 2025).

Bug Issue Report

Describe the problem

After upgrading from version 0.45.1 to version 0.45.2, the Networks functionality in NetBird is not working properly. The services configured are unable to be accessed.

To Reproduce

Steps to reproduce the behavior:

  1. Upgrade NetBird from version 0.45.1 to 0.45.2.
  2. Attempt to access a configured service through the Networks feature.
  3. See error or no connectivity.

Expected behavior

The Network services should be accessible and functioning correctly as they were in the previous version (0.45.1).

Are you using NetBird Cloud?

self-host NetBird's control plane.

NetBird version

netbird version: 0.45.2

Is any other VPN software installed?

If yes, which one?

  • Yes
  • [] No
Originally created by @Cikaros on GitHub (May 31, 2025). ### Bug Issue Report **Describe the problem** After upgrading from version 0.45.1 to version 0.45.2, the Networks functionality in NetBird is not working properly. The services configured are unable to be accessed. **To Reproduce** Steps to reproduce the behavior: 1. Upgrade NetBird from version 0.45.1 to 0.45.2. 2. Attempt to access a configured service through the Networks feature. 3. See error or no connectivity. **Expected behavior** The Network services should be accessible and functioning correctly as they were in the previous version (0.45.1). **Are you using NetBird Cloud?** self-host NetBird's control plane. **NetBird version** `netbird version: 0.45.2` **Is any other VPN software installed?** If yes, which one? - [x] Yes - [] No
saavagebueno added the triage-needed label 2025-11-20 06:09:30 -05:00
saavagebueno commented 2025-11-20 06:09:31 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (May 31, 2025):

@Cikaros, we are missing the required debug logs. Can you please run:

netbird debug bundle -U -AS

If the failure still happening, can you also collect the Wireguard status:

sudo wg show | egrep 'peer|allowed'
@mlsmaycon commented on GitHub (May 31, 2025): @Cikaros, we are missing the required debug logs. Can you please run: ``` netbird debug bundle -U -AS ``` If the failure still happening, can you also collect the Wireguard status: ```shell sudo wg show | egrep 'peer|allowed' ```
saavagebueno commented 2025-11-20 06:09:31 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (May 31, 2025):

can you share Wireguard status too?

you might need to install wireguard-tools via homebrew

Also, is this route running in high availability mode?

@mlsmaycon commented on GitHub (May 31, 2025): can you share Wireguard status too? you might need to install `wireguard-tools` via homebrew Also, is this route running in high availability mode?
saavagebueno commented 2025-11-20 06:09:32 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (May 31, 2025):

It is not in high-performance mode, there is only one active node, and it is currently online.

@Cikaros commented on GitHub (May 31, 2025): It is not in high-performance mode, there is only one active node, and it is currently online.
saavagebueno commented 2025-11-20 06:09:32 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (May 31, 2025):

Ok, it seems like the client didn't add the 172.18.0.10/32 range into your node's routing table.

We will check the logs and to see if we find something.

@mlsmaycon commented on GitHub (May 31, 2025): Ok, it seems like the client didn't add the `172.18.0.10/32` range into your node's routing table. We will check the logs and to see if we find something.
saavagebueno commented 2025-11-20 06:09:32 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (May 31, 2025):

Sure, the previous version is available.

@Cikaros commented on GitHub (May 31, 2025): Sure, the previous version is available.
saavagebueno commented 2025-11-20 06:09:32 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 2, 2025):

netird 0.45.3 still has this issue

@Cikaros commented on GitHub (Jun 2, 2025): netird 0.45.3 still has this issue
saavagebueno commented 2025-11-20 06:09:32 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 2, 2025):

When checking the Signal server logs, it was found that:

2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"
2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"
2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"
2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"
2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"
2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"
2025-06-02T10:01:46Z INFO ./caller_not_available:0: 2025/06/02 10:01:46 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"
2025-06-02T10:01:49Z INFO ./caller_not_available:0: 2025/06/02 10:01:49 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"
2025-06-02T10:01:49Z INFO ./caller_not_available:0: 2025/06/02 10:01:49 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"
@Cikaros commented on GitHub (Jun 2, 2025): When checking the Signal server logs, it was found that: ``` 2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing" 2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing" 2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing" 2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing" 2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing" 2025-06-02T10:01:43Z INFO ./caller_not_available:0: 2025/06/02 10:01:43 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing" 2025-06-02T10:01:46Z INFO ./caller_not_available:0: 2025/06/02 10:01:46 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing" 2025-06-02T10:01:49Z INFO ./caller_not_available:0: 2025/06/02 10:01:49 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing" 2025-06-02T10:01:49Z INFO ./caller_not_available:0: 2025/06/02 10:01:49 WARNING: [core] [Server #1]grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing" ```
saavagebueno commented 2025-11-20 06:09:32 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 2, 2025):

@Cikaros, thanks for sharing a status update on this. We are attempting to reproduce the issue without success.

Can you confirm if the issue happens after returning from sleep mode and can you please run the following commands:

# enable trace logs
netbird debug log level trace
# start collecting debugging data netbird for 2 minutes
netbird debug for 2m --upload-bundle --anonymize

In parallel run the usual network tests for this resource (172.18.0.10/32) and also run the following commands to collect routing table and wireguard info:

sudo wg show | egrep 'peer|allowed'
netstart -nr | grep 172

If, during the 2 minutes, the route works, we might need to wait until it fails again, and in that time, you can run the following command to get a debug bundle and collect the routing table and wireguard info again.

netbird debug bundle --upload-bundle --anonymize
sudo wg show | egrep 'peer|allowed'
netstart -nr | grep 172

In all cases, please share the Upload key for the bundle and the output of netstat and wg commands.

@mlsmaycon commented on GitHub (Jun 2, 2025): @Cikaros, thanks for sharing a status update on this. We are attempting to reproduce the issue without success. Can you confirm if the issue happens after returning from sleep mode and can you please run the following commands: ```shell # enable trace logs netbird debug log level trace # start collecting debugging data netbird for 2 minutes netbird debug for 2m --upload-bundle --anonymize ``` In parallel run the usual network tests for this resource (172.18.0.10/32) and also run the following commands to collect routing table and wireguard info: ```shell sudo wg show | egrep 'peer|allowed' netstart -nr | grep 172 ``` If, during the 2 minutes, the route works, we might need to wait until it fails again, and in that time, you can run the following command to get a debug bundle and collect the routing table and wireguard info again. ```shell netbird debug bundle --upload-bundle --anonymize sudo wg show | egrep 'peer|allowed' netstart -nr | grep 172 ``` In all cases, please share the Upload key for the bundle and the output of netstat and wg commands.
saavagebueno commented 2025-11-20 06:09:33 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 2, 2025):

Current server setup:
Server A:

Netbird client 0.45.3
DNS (in Docker) at 172.18.0.10
MacOS B:

Netbird client 0.45.3
Windows C:

Netbird client 0.45.3
Using Networks, the DNS on Server A (172.18.0.10) is intended to be accessible by both B and C, with custom DNS settings pushing 172.18.0.10 to B and C.

At the moment, both B and C cannot access 172.18.0.10 (even though the relevant ports have been opened).

@Cikaros commented on GitHub (Jun 2, 2025): Current server setup: Server A: Netbird client 0.45.3 DNS (in Docker) at 172.18.0.10 MacOS B: Netbird client 0.45.3 Windows C: Netbird client 0.45.3 Using Networks, the DNS on Server A (172.18.0.10) is intended to be accessible by both B and C, with custom DNS settings pushing 172.18.0.10 to B and C. At the moment, both B and C cannot access 172.18.0.10 (even though the relevant ports have been opened).
saavagebueno commented 2025-11-20 06:09:33 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 2, 2025):

@Cikaros from my last comment: https://github.com/netbirdio/netbird/issues/3905#issuecomment-2929859171

You can replace the netstat command with route print, and the wg command would need you to install wireguard using https://www.wireguard.com/install/

@mlsmaycon commented on GitHub (Jun 2, 2025): @Cikaros from my last comment: https://github.com/netbirdio/netbird/issues/3905#issuecomment-2929859171 You can replace the netstat command with `route print`, and the wg command would need you to install wireguard using https://www.wireguard.com/install/
saavagebueno commented 2025-11-20 06:09:33 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 2, 2025):

Please accept the information as soon as possible, and then I will delete the record.

@Cikaros commented on GitHub (Jun 2, 2025): Please accept the information as soon as possible, and then I will delete the record.
saavagebueno commented 2025-11-20 06:09:33 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 2, 2025):

I copied the info above.

Can you confirm that during the time when you captured the info, the route was working right?

@mlsmaycon commented on GitHub (Jun 2, 2025): I copied the info above. Can you confirm that during the time when you captured the info, the route was working right?
saavagebueno commented 2025-11-20 06:09:33 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 2, 2025):

The resource has not been accessible during the capture.

@Cikaros commented on GitHub (Jun 2, 2025): The resource has not been accessible during the capture.
saavagebueno commented 2025-11-20 06:09:33 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 6, 2025):

@mlsmaycon During the troubleshooting process, it was discovered that this issue originates from the Routing Peer. In previous versions, the Routing Peer was able to forward any IP resources that it could access directly. However, in the upgraded version, while it is still possible to access resources on the physical network interface, issues arise when attempting to access IP resources located in virtual bridges created by Docker — in such cases, those resources become inaccessible.

@Cikaros commented on GitHub (Jun 6, 2025): @mlsmaycon During the troubleshooting process, it was discovered that this issue originates from the Routing Peer. In previous versions, the Routing Peer was able to forward any IP resources that it could access directly. However, in the upgraded version, while it is still possible to access resources on the physical network interface, issues arise when attempting to access IP resources located in virtual bridges created by Docker — in such cases, those resources become inaccessible.
saavagebueno commented 2025-11-20 06:09:33 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 7, 2025):

The problem might be related to the operating system. There is no such issue when using the Docker version of Routing peer. Do any of the developers have any ideas? I'll go and verify this.

@Cikaros commented on GitHub (Jun 7, 2025): The problem might be related to the operating system. There is no such issue when using the Docker version of Routing peer. Do any of the developers have any ideas? I'll go and verify this.
saavagebueno commented 2025-11-20 06:09:34 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 11, 2025):

@mlsmaycon After multiple tests, it was found that the Routing Peer can normally access Networks resources in an aarch64 environment, but the Routing Peer cannot access Networks resources in an x64 environment.

@Cikaros commented on GitHub (Jun 11, 2025): @mlsmaycon After multiple tests, it was found that the Routing Peer can normally access Networks resources in an aarch64 environment, but the Routing Peer cannot access Networks resources in an x64 environment.
saavagebueno commented 2025-11-20 06:09:34 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 11, 2025):

Me ======> X64 Peer ----❌---> Networks Resource
Me ======> aarch64 Peer ----✅---> Networks Resource

@Cikaros commented on GitHub (Jun 11, 2025): Me ======> X64 Peer ----❌---> Networks Resource Me ======> aarch64 Peer ----✅---> Networks Resource
saavagebueno commented 2025-11-20 06:09:34 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 11, 2025):

can you please run netbird debug bundle --upload-bundle on both versions and share them with us?

Can you also confirm how did you run the tests? and confirmed that one version is not forwarding traffic?

@mlsmaycon commented on GitHub (Jun 11, 2025): can you please run `netbird debug bundle --upload-bundle` on both versions and share them with us? Can you also confirm how did you run the tests? and confirmed that one version is not forwarding traffic?
saavagebueno commented 2025-11-20 06:09:34 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 11, 2025):

I proactively configured two Networks and added a Peer to each. Then, I configured host private resources for these two Networks and opened resource permissions to a third-party Group (Me). The confirmation method currently involves directly accessing the port via curl or telnet.

@Cikaros commented on GitHub (Jun 11, 2025): I proactively configured two Networks and added a Peer to each. Then, I configured host private resources for these two Networks and opened resource permissions to a third-party Group (Me). The confirmation method currently involves directly accessing the port via curl or telnet.
saavagebueno commented 2025-11-20 06:09:34 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 11, 2025):

Ok, can you revalidate it and when testing please run tcpdump dump on the routing peers to ensure the traffic is flowing? if you send me the destination address and port I can share a command for it.

Also, which OS you are using for routing peer?

@mlsmaycon commented on GitHub (Jun 11, 2025): Ok, can you revalidate it and when testing please run tcpdump dump on the routing peers to ensure the traffic is flowing? if you send me the destination address and port I can share a command for it. Also, which OS you are using for routing peer?
saavagebueno commented 2025-11-20 06:09:34 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 11, 2025):

Image How can I set up a proxy to complete the upload?
@Cikaros commented on GitHub (Jun 11, 2025): <img width="1276" alt="Image" src="https://github.com/user-attachments/assets/6c333c21-d648-4298-aba8-5df2e4b6b781" /> How can I set up a proxy to complete the upload?
saavagebueno commented 2025-11-20 06:09:35 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 11, 2025):

  • Me(MacOS) private Group
  • Networks(Ubuntu Linux) vps Group
    • 172.18.0.10:53 (TCP And UDP)
@Cikaros commented on GitHub (Jun 11, 2025): - Me(MacOS) private Group - Networks(Ubuntu Linux) vps Group - 172.18.0.10:53 (TCP And UDP)
saavagebueno commented 2025-11-20 06:09:35 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 11, 2025):

The command is:

sudo tcpdump -i any -nn host 172.18.0.10 and port 53

Can you share the files generated then?

@mlsmaycon commented on GitHub (Jun 11, 2025): The command is: ```shell sudo tcpdump -i any -nn host 172.18.0.10 and port 53 ``` Can you share the files generated then?
saavagebueno commented 2025-11-20 06:09:35 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 11, 2025):

root@RainYun-5SfBJ4Bx:~# sudo tcpdump -i any -nn host 172.18.0.10 and port 53
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
18:15:44.618309 wt0   In  IP 100.73.77.121.61739 > 172.18.0.10.53: 61616+ SOA? com. (21)
18:15:51.024141 wt0   In  IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275480864 ecr 0,sackOK,eol], length 0
18:15:51.248496 wt0   In  IP 100.73.98.38.64562 > 172.18.0.10.53: 12122+ SOA? com. (21)
18:15:51.730024 wt0   In  IP 100.73.77.121.64317 > 172.18.0.10.53: 1070+ SOA? com. (21)
18:15:52.024765 wt0   In  IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275481865 ecr 0,sackOK,eol], length 0
18:15:53.027073 wt0   In  IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275482866 ecr 0,sackOK,eol], length 0
18:15:54.030830 wt0   In  IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275483867 ecr 0,sackOK,eol], length 0
18:15:55.028464 wt0   In  IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275484868 ecr 0,sackOK,eol], length 0
18:15:56.033103 wt0   In  IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275485869 ecr 0,sackOK,eol], length 0
18:15:58.029792 wt0   In  IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275487870 ecr 0,sackOK,eol], length 0
18:16:00.492165 wt0   In  IP 100.73.98.38.60365 > 172.18.0.10.53: 22308+ SOA? com. (21)
18:16:02.032779 wt0   In  IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275491871 ecr 0,sackOK,eol], length 0
18:16:08.478796 wt0   In  IP 100.73.77.121.58877 > 172.18.0.10.53: 12448+ SOA? com. (21)
18:16:10.031728 wt0   In  IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275499871 ecr 0,sackOK,eol], length 0
18:16:13.763080 wt0   In  IP 100.73.98.38.57834 > 172.18.0.10.53: 539+ SOA? com. (21)
18:16:18.855031 wt0   In  IP 100.73.77.121.49553 > 172.18.0.10.53: 21487+ SOA? com. (21)
18:16:19.837882 wt0   In  IP 100.73.77.121.52082 > 172.18.0.10.53: 1327+ SOA? com. (21)
18:16:20.218362 wt0   In  IP 100.73.98.38.57741 > 172.18.0.10.53: 23358+ SOA? com. (21)
18:16:22.450182 wt0   In  IP 100.73.77.121.52083 > 172.18.0.10.53: 2186+ SOA? com. (21)
18:16:27.038011 wt0   In  IP 100.73.98.38.62182 > 172.18.0.10.53: 53151+ SOA? com. (21)
^Z
[1]+  Stopped                 sudo tcpdump -i any -nn host 172.18.0.10 and port 53
@Cikaros commented on GitHub (Jun 11, 2025): ``` root@RainYun-5SfBJ4Bx:~# sudo tcpdump -i any -nn host 172.18.0.10 and port 53 tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 18:15:44.618309 wt0 In IP 100.73.77.121.61739 > 172.18.0.10.53: 61616+ SOA? com. (21) 18:15:51.024141 wt0 In IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275480864 ecr 0,sackOK,eol], length 0 18:15:51.248496 wt0 In IP 100.73.98.38.64562 > 172.18.0.10.53: 12122+ SOA? com. (21) 18:15:51.730024 wt0 In IP 100.73.77.121.64317 > 172.18.0.10.53: 1070+ SOA? com. (21) 18:15:52.024765 wt0 In IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275481865 ecr 0,sackOK,eol], length 0 18:15:53.027073 wt0 In IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275482866 ecr 0,sackOK,eol], length 0 18:15:54.030830 wt0 In IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275483867 ecr 0,sackOK,eol], length 0 18:15:55.028464 wt0 In IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275484868 ecr 0,sackOK,eol], length 0 18:15:56.033103 wt0 In IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275485869 ecr 0,sackOK,eol], length 0 18:15:58.029792 wt0 In IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275487870 ecr 0,sackOK,eol], length 0 18:16:00.492165 wt0 In IP 100.73.98.38.60365 > 172.18.0.10.53: 22308+ SOA? com. (21) 18:16:02.032779 wt0 In IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275491871 ecr 0,sackOK,eol], length 0 18:16:08.478796 wt0 In IP 100.73.77.121.58877 > 172.18.0.10.53: 12448+ SOA? com. (21) 18:16:10.031728 wt0 In IP 100.73.98.38.58005 > 172.18.0.10.53: Flags [S], seq 833646018, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 275499871 ecr 0,sackOK,eol], length 0 18:16:13.763080 wt0 In IP 100.73.98.38.57834 > 172.18.0.10.53: 539+ SOA? com. (21) 18:16:18.855031 wt0 In IP 100.73.77.121.49553 > 172.18.0.10.53: 21487+ SOA? com. (21) 18:16:19.837882 wt0 In IP 100.73.77.121.52082 > 172.18.0.10.53: 1327+ SOA? com. (21) 18:16:20.218362 wt0 In IP 100.73.98.38.57741 > 172.18.0.10.53: 23358+ SOA? com. (21) 18:16:22.450182 wt0 In IP 100.73.77.121.52083 > 172.18.0.10.53: 2186+ SOA? com. (21) 18:16:27.038011 wt0 In IP 100.73.98.38.62182 > 172.18.0.10.53: 53151+ SOA? com. (21) ^Z [1]+ Stopped sudo tcpdump -i any -nn host 172.18.0.10 and port 53 ```
saavagebueno commented 2025-11-20 06:09:35 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 11, 2025):

So it does seem to have traffic coming in, but I don't understand why it's not accessible. In Ubuntu Linux, direct access to 172.18.0.10:53 is possible. Here is an overview of the environment:
Ubuntu Linux:

  • Peer wt0:100.73.136.130
  • Docker:
    • 172.18.0.10 DNS
@Cikaros commented on GitHub (Jun 11, 2025): So it does seem to have traffic coming in, but I don't understand why it's not accessible. In Ubuntu Linux, direct access to 172.18.0.10:53 is possible. Here is an overview of the environment: Ubuntu Linux: - Peer wt0:100.73.136.130 - Docker: - 172.18.0.10 DNS
saavagebueno commented 2025-11-20 06:09:35 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 16, 2025):

I apologize for the inconvenience. After re-checking the iptables and replacing it with nftables, the network is now functioning normally.

@Cikaros commented on GitHub (Jun 16, 2025): I apologize for the inconvenience. After re-checking the iptables and replacing it with nftables, the network is now functioning normally.
saavagebueno commented 2025-11-20 06:09:35 -05:00
Author
Owner
Copy Link

@Cikaros commented on GitHub (Jun 23, 2025):

Problem background: Before this, there had never been an issue with Networks being inaccessible during the self-deployment of Netbird. After a preliminary check with telnet, it was mistakenly believed to be a forwarding issue with netbird-client, leading to this bug report.

Problem cause: Since the official deployment environment supports Docker, the issue this time is related to Docker's iptables. Although Docker is configured with iptables=true, there are still forwarding issues.

Personal solution: Installing ufw and disabling Docker's iptables support switch, by manually configuring firewall rules, this event was resolved.

@Cikaros commented on GitHub (Jun 23, 2025): **Problem background**: Before this, there had never been an issue with Networks being inaccessible during the self-deployment of Netbird. After a preliminary check with telnet, it was mistakenly believed to be a forwarding issue with netbird-client, leading to this bug report. **Problem cause**: Since the official deployment environment supports Docker, the issue this time is related to Docker's iptables. Although Docker is configured with `iptables=true`, there are still forwarding issues. **Personal solution**: Installing ufw and disabling Docker's iptables support switch, by manually configuring firewall rules, this event was resolved.
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 triage-needed
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#1930
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?