Messages

Updated to 26.7.1_1. Tested this by adding Netbird Interface and rebooting, it works now.

Thanx for the fix guys! Can finally reach router itself through Netbird

Ok thanx. So fix is clear, but will take a while to get implemented everywhere.
Will be checking those release notes every update.

It's not a restore. It's a clean setup, spent 2 days precisely settings things up again. Got everything working (vlans, wireguard, firewall rules, nat, dns, custom cron scripts for ddns etc)

I rebooted after every change to see what broke it. It's not just enabling the NetBird plugin, then it reboots fine. The moment i assign it to an interface and enable it, rebooting falls back to default config.

I was running OPNsense 25.7 with the Netbird plugin (os-netbird) just fine. My hardware broke, switched to new hardware and OPNsense 26.1.6. Got everything setup again, just kept having reboots fail. After hours of headaches i found out it's the Netbird plugin. But not just the Netbird plugin, it's only when i assign it as an interface, so i can add firewall to access the OPNsense router itself through the Netbird tunnel. On 25.7 i had no issues with this over reboots.

Booting now ends in default config, it doesn't seem to load /conf/config.xml fully. Also no indications it is corrupt, and it looks just the same as before the interface assignment. This is what boot shows. Couldn't copy paste from the console where router is, so typed it from photo:

started daemon server: /var/run/netbird.sock
Starting Netbird client version 0.66.3
WARNING [core] grpc: addrConn.createTransport failed to connect to {Addr: "mynetbird.controlserver.domain:443"}.
connection error: Error while dialing: nbnet.NewDialer().DialContext: d.Dialer.DialContext: dial tcp: lookup on mynetbird.controlserver.domain [2620:fe::9]:53: dial udp: lookup on mynetbird.controlserver.domain [2620:fe::9]:53:
connect: no route to host
WARNING [core] grpc: addrConn.createTransport failed to connect to {Addr: "192.ipaddress.of.netbirdcontrolserver:443"}.
connection error: Error while dialing: nbnet.NewDialer().DialContext: d.Dialer.DialContext: dial tcp: lookup on 192.ipaddress.of.netbirdcontrolserver [2620:fe::9]:53: dial udp: lookup on 192.ipaddress.of.netbirdcontrolserver [2620:fe::9]:53:
connect: no route to host

So 2620:fe::9 is a DNS server i have under Settings/General (backup, because i use Unbound to forward to Technitium). Maybe this is a race thing? I noticed in rc.d that Netbird required "SERVER", should that be something else like "NETWORK"? Also i find it strange that it stops booting from config.xml and just drops back to default.

Is this a bug or something i'm doing wrong?

Clear, thanx!

Yes, i noticed that broke things rather than improve them. I was just shooting blind and hoping to hit.
No Group rules, the issue was the "reply-to" set to default. Changing that to the interace through which the traffic came in fixed it. The weird thing is, it used to work with reply-to set to default and that still works on my WAN. So maybe something changed where a VPN is on another interface, WAN in my case.

Awesome, i thought i had tried that, but i just had set the regular Gateway to AirVPN_Torrent.
Now there is traffice returning and the port shows open.

Is this a bug or is expected in these kind of configurations that the default "reply-to" does not work?
The setup worked before with the default reply-to

I have an AirVPN OpenVPN (UDP ipv4) interface and a local HIDEME vlan with a torrent client in it. When i initiate traffic from the client on HIDEME traffic goes out through the VPN and i get reply back, no issues there. For torrent uploading (BSD and Linus iso's) i have port forward setup on AirVPN side. The port is 23407 all the way from AirVPN through NAT port forward and torrent client. Firewall rules have the default reply-to active and i do not specify a gateway on the incoming firewall rules. I can reach my client on HIDEME vlan through AirVPN exit ip:port, but traffic does not seem to be returned. 0 upload. When i do the same on my WAN, everything works fine, full upload speed.

I ran TCPDUMP and noticed incoming packet length is 0 (TCP) on the AirVPN where WAN has >0. The traffic does reach the torrent client, who wants to send something back, but it doesn't show up in the interface for AirVPN_Torrent. Is the 0 packet size causing this or is return traffic ending up somewhere else?

# is to prevent markup here from the letter before it

AirVPN_Torrent
11:26:13.119590 IP 39.40.78.209.51929 > 10.17.130.46.23407: Flags [S#], seq 1279553544, win 64240, options [mss 1375,nop,wscale 8,nop,nop,sackOK], length 0

HIDEME TCPDUMP
11:26:13.119608 IP 39.40.78.209.51929 > torrent.home.23407: Flags [S#], seq 1279553544, win 64240, options [mss 1375,nop,wscale 8,nop,nop,sackOK], length 0
11:26:13.119711 IP torrent.home.23407 > 39.40.78.209.51929: Flags [S#], seq 4011136359, ack 1279553545, win 64240, options [mss 1460], length 0



YOUFONE (WAN)
11:35:12.939709 IP 185.107.44.124.59288 > 77-172-30-35.fixed.kpn.net.23407: Flags [P.], seq 2212:2221, ack 3196540, win 12284, options [nop,nop,TS val 3854412952 ecr 1074413978], length 9
11:35:13.181938 IP 185.107.44.124.59288 > 77-172-30-35.fixed.kpn.net.23407: Flags [P.], seq 2221:3241, ack 3196540, win 12284, options [nop,nop,TS val 3854413194 ecr 1074413984], length 1020
11:35:13.209111 IP 77-172-30-35.fixed.kpn.net.23407 > 185.107.44.124.59288: Flags [.], seq 3307924:3309352, ack 3259, win 501, options [nop,nop,TS val 1074414252 ecr 3854413205], length 1428

HIDEME
11:35:13.181951 IP 185.107.44.124.59288 > torrent.home.23407: Flags [P.], seq 35:1055, ack 1, win 12284, options [nop,nop,TS val 3854413194 ecr 1074413984], length 1020
11:35:13.207906 IP torrent.home.23407 > 185.107.44.124.59288: Flags [.], seq 1:1429, ack 1073, win 501, options [nop,nop,TS val 1074414252 ecr 3854413205], length 1428