[GH-ISSUE #5895] Internal Reverse Proxy #11880

New Issue

saavagebueno · 2026-08-05T01:31:26-04:00

saavagebueno commented

2026-08-05 01:31:26 -04:00

Originally created by @ITCMD on GitHub (Apr 15, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5895

Is your feature request related to a problem? Please describe.
We've got numerous devices and services at customer locations we'd love to access via a direct dns query. IE device 192.168.1.40 on network b. We'd love to create a dns zone device.customerxyz.com and have it forward to that device, including port options. We can do this on the public internet using the reverse proxy setup, but we're using nginx and do not have any proxy clusters setup. However, that should not be needed if we want to only expose it internally. We can expose devices as resources, but this is only IP so it doesn't help with non-standard ports and does not work if the IPs conflict with another resource.

Describe the solution you'd like
Add an internal reverse proxy where you could setup something like:

doman: printer.greenstreet.company.com
Device: 192.168.1.21 port 8080
Via peer: (select a peer or peer group)

Then when I visit printer.greenstreet.company.com while connected to netbird, it routes with a valid https and without needing to enter in port 8080. It would need to have its own generated IP on the netbird network or a similar one for the DNS to work, I am guessing.

Describe alternatives you've considered
I have considered using the existing remote proxy service, but I do not want to setup proxy clusters as there is nothing we would want to expose to the public internet. We've also considered just exposing the service, but then we still have to manually type in the port and manage ip conflicts.

Originally created by @ITCMD on GitHub (Apr 15, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5895 **Is your feature request related to a problem? Please describe.** We've got numerous devices and services at customer locations we'd love to access via a direct dns query. IE device 192.168.1.40 on network b. We'd love to create a dns zone device.customerxyz.com and have it forward to that device, including port options. We can do this on the public internet using the reverse proxy setup, but we're using nginx and do not have any proxy clusters setup. However, that should not be needed if we want to only expose it internally. We can expose devices as resources, but this is only IP so it doesn't help with non-standard ports and does not work if the IPs conflict with another resource. **Describe the solution you'd like** Add an internal reverse proxy where you could setup something like: - doman: printer.greenstreet.company.com - Device: 192.168.1.21 port 8080 - Via peer: (select a peer or peer group) Then when I visit printer.greenstreet.company.com while connected to netbird, it routes with a valid https and without needing to enter in port 8080. It would need to have its own generated IP on the netbird network or a similar one for the DNS to work, I am guessing. **Describe alternatives you've considered** I have considered using the existing remote proxy service, but I do not want to setup proxy clusters as there is nothing we would want to expose to the public internet. We've also considered just exposing the service, but then we still have to manually type in the port and manage ip conflicts.

saavagebueno added the feature-request label 2026-08-05 01:31:26 -04:00

saavagebueno commented

2026-08-05 01:31:27 -04:00

@NoNaccc commented on GitHub (Apr 18, 2026):

+1 on this.

To simplify the ask: right now the reverse proxy is designed to expose services to the public internet. But many of us need the same functionality — nice DNS names, automatic TLS, port abstraction — purely internally, only for clients connected to the NetBird mesh.

This is closely related to #5556 , which I opened a while back. My request there was about allowing auth bypass based on source IP/CIDR (e.g. 100.64.0.0/10) so that VPN-connected clients don't have to go through SSO again. Both issues boil down to the same underlying gap: there's no clean way to use the reverse proxy for internal-only services.

Right now there's a clear gap between Networks (internal, but IP-only, no TLS, no port mapping) and the Reverse Proxy (DNS + TLS + port mapping, but public-facing). The missing piece is an internal reverse proxy that combines the convenience of the reverse proxy with the scope of Networks — only reachable for connected peers, with proper DNS and TLS, without needing proxy clusters or public certificate validation.

@NoNaccc commented on GitHub (Apr 18, 2026): +1 on this. To simplify the ask: right now the reverse proxy is designed to expose services to the public internet. But many of us need the same functionality — nice DNS names, automatic TLS, port abstraction — purely internally, only for clients connected to the NetBird mesh. This is closely related to #5556 , which I opened a while back. My request there was about allowing auth bypass based on source IP/CIDR (e.g. 100.64.0.0/10) so that VPN-connected clients don't have to go through SSO again. Both issues boil down to the same underlying gap: there's no clean way to use the reverse proxy for internal-only services. Right now there's a clear gap between Networks (internal, but IP-only, no TLS, no port mapping) and the Reverse Proxy (DNS + TLS + port mapping, but public-facing). The missing piece is an internal reverse proxy that combines the convenience of the reverse proxy with the scope of Networks — only reachable for connected peers, with proper DNS and TLS, without needing proxy clusters or public certificate validation.

saavagebueno commented

2026-08-05 01:31:27 -04:00

@elia2904 commented on GitHub (Apr 20, 2026):

+1 on this.
That's a feature I would find very helpfull.

@elia2904 commented on GitHub (Apr 20, 2026): +1 on this. That's a feature I would find very helpfull.

saavagebueno commented

2026-08-05 01:31:27 -04:00

@Minimalist-2211 commented on GitHub (Apr 20, 2026):

We need this, pls NetBird! 🙏

@Minimalist-2211 commented on GitHub (Apr 20, 2026): We need this, pls NetBird! 🙏

saavagebueno commented

2026-08-05 01:31:27 -04:00

@Silvani-In-The-Net commented on GitHub (Apr 20, 2026):

I also second this, I use an external domain that I allow family to use through Pangolin-Reverse proxy for things like Jellyfin. This feature would allow me to completely swap over to this for both my external and internal services for which I still rely on Caddy (with Self Signed Certs).

@Silvani-In-The-Net commented on GitHub (Apr 20, 2026): I also second this, I use an external domain that I allow family to use through Pangolin-Reverse proxy for things like Jellyfin. This feature would allow me to completely swap over to this for both my external and internal services for which I still rely on Caddy (with Self Signed Certs).

saavagebueno commented

2026-08-05 01:31:27 -04:00

@Minimalist-2211 commented on GitHub (Apr 21, 2026):

I also second this, I use an external domain that I allow family to use through another proxy service for things like Jellyfin. This feature would allow me to completely swap over to this for both my external and internal services for which I still rely on Caddy (with Self Signed Certs).

Same!

@Minimalist-2211 commented on GitHub (Apr 21, 2026): > I also second this, I use an external domain that I allow family to use through another proxy service for things like Jellyfin. This feature would allow me to completely swap over to this for both my external and internal services for which I still rely on Caddy (with Self Signed Certs). Same!

saavagebueno commented

2026-08-05 01:31:27 -04:00

@dasunsrule32 commented on GitHub (Apr 30, 2026):

As @NoNaccc said earlier, with the internal proxy, it would be nice to deploy the proxy on-premise to handle TLS negotiation, have a local IP and can connect to the backend services there. Then policies can define access over the Netbird client.

It would also be nice to have flexibility to access those same services locally via the on-premise proxy. I think it should work similarly to how the public services work where you don't need to be connected to the client and can still hit those services.

Pangolin has added internal proxy support, however, there implementation will still go out to their server for services on the same network, which I don't want.

Currently, I deploy Caddy on prem and point Pangolin to it. Netbird doesn't handle TLS SNI Server Names currently, so I can't use that connection without a bunch of janky changes in Caddy. Pangolin lets you set that feature directly in the proxy settings.

@dasunsrule32 commented on GitHub (Apr 30, 2026): As @NoNaccc said earlier, with the internal proxy, it would be nice to deploy the proxy on-premise to handle TLS negotiation, have a local IP and can connect to the backend services there. Then policies can define access over the Netbird client. It would also be nice to have flexibility to access those same services locally via the on-premise proxy. I think it should work similarly to how the public services work where you don't need to be connected to the client and can still hit those services. Pangolin has added internal proxy support, however, there implementation will still go out to their server for services on the same network, which I don't want. Currently, I deploy Caddy on prem and point Pangolin to it. Netbird doesn't handle TLS SNI Server Names currently, so I can't use that connection without a bunch of janky changes in Caddy. Pangolin lets you set that feature directly in the proxy settings.

saavagebueno commented

2026-08-05 01:31:27 -04:00

@WirtsLegs commented on GitHub (May 6, 2026):

Big +1 from me, probably the single most significant missing feature for me. I have a limited but distributed user-base and need to be able to cleanly control access to services for them, without making those services available to the open internet

@WirtsLegs commented on GitHub (May 6, 2026): Big +1 from me, probably the single most significant missing feature for me. I have a limited but distributed user-base and need to be able to cleanly control access to services for them, without making those services available to the open internet

saavagebueno commented

2026-08-05 01:31:27 -04:00

@timthelion commented on GitHub (May 16, 2026):

I would love this too. Even better if it supported wildcards.

@timthelion commented on GitHub (May 16, 2026): I would love this too. Even better if it supported wildcards.

saavagebueno commented

2026-08-05 01:31:27 -04:00

@chadillac commented on GitHub (May 20, 2026):

Another +1 for this... spent some time thinking about it, and I think if network route peers could also serve as revproxy service exposures with the DNS zones, you could achieve something like this...

internal DNS: .lan
network: 192.168.10.0/24
route peer: server.lan (192.168.10.0/24)
peer service:
  |- mything.lan -> server.lan:8080
  |- otherthing.lan -> server.lan:1111
  |- gateway.lan -> 192.168.10.1:8443

So with this setup, check the zone, if no resource exists at the name, check the service, as the route peer is routed the traffic, it can either masquerade it along, or it can redirect it into it's native revproxy which then routes in through to the expected port mapping on the peer.

So visiting gateway.lan on the nb peer would result in traffic routing to the server.lan peer, and then acting as a revproxy to 192.168.10.1:8443 to get to the LAN gateway admin login page.

Just my $0.02

To get around this lack of feature, I was planning to deploy an internal revproxy myself that will do something like this for being able to easily expose services to netbird peers using a similar pattern.

@chadillac commented on GitHub (May 20, 2026): Another +1 for this... spent some time thinking about it, and I think if network route peers could also serve as revproxy service exposures with the DNS zones, you could achieve something like this... ``` internal DNS: .lan network: 192.168.10.0/24 route peer: server.lan (192.168.10.0/24) peer service: |- mything.lan -> server.lan:8080 |- otherthing.lan -> server.lan:1111 |- gateway.lan -> 192.168.10.1:8443 ``` So with this setup, check the zone, if no resource exists at the name, check the service, as the route peer is routed the traffic, it can either masquerade it along, or it can redirect it into it's native revproxy which then routes in through to the expected port mapping on the peer. So visiting `gateway.lan` on the nb peer would result in traffic routing to the `server.lan` peer, and then acting as a revproxy to `192.168.10.1:8443` to get to the LAN gateway admin login page. Just my $0.02 To get around this lack of feature, I was planning to deploy an internal revproxy myself that will do something like this for being able to easily expose services to netbird peers using a similar pattern.

saavagebueno commented

2026-08-05 01:31:27 -04:00

@SneakyTurt1e commented on GitHub (May 28, 2026):

+1 on this.
I think it's quite useful within our docker lab... even we can setup custom DNS domain for netbird network, but it's pain to remember all ports we using with docker container.

@SneakyTurt1e commented on GitHub (May 28, 2026): +1 on this. I think it's quite useful within our docker lab... even we can setup custom DNS domain for netbird network, but it's pain to remember all ports we using with docker container.

saavagebueno commented

2026-08-05 01:31:27 -04:00

@erdelmaero commented on GitHub (Jun 2, 2026):

+1 on this — would let us collapse a duplicated piece of our stack.

We currently do use netbird-proxy for public service exposure and it's been
great there. The gap is on the internal side: any service that should only be
reachable from inside the mesh still goes through a separate Traefik instance
we maintain ourselves. The pattern is:

service runs in our k8s cluster, no public DNS A record, no public IP
internal Traefik handles TLS termination (wildcard LE cert via DNS-01,
managed by cert-manager), forward-auth via oauth2-proxy, host-based routing
the NetBird DNS we serve to mesh peers points to that Traefik's LB IP
peer hits e.g. argocd.contoso.com → Traefik → backend pod

It works, but we're effectively maintaining two reverse proxies for what is
conceptually one capability — "give peers a friendly hostname, terminate TLS,
optionally gate with SSO". The reverse-proxy already does all that for public
services. For internal-only services, all we want is for it to:

not require a public DNS A record / publicly resolvable hostname for each
service (DNS-01 wildcard already covers TLS; the per-host A record only
exists today to satisfy the public-exposure assumption)
run on a peer inside the mesh rather than the public exposure VM

I think the underlying need — NetBird as ZTN + an internal reverse proxy in
front of mesh-only services — is a very common architecture. Today users
either do what we do (separate reverse proxy + NetBird DNS pointing at it),
or fall back to bare IPs + remembering port numbers. Both are worse than
having this in one product.

@chadillac's sketch a few comments up matches our case almost exactly. The
one thing we'd most want layered on top is the same per-service group ACLs
the public reverse proxy already has, so we can keep the SSO / per-group
access model unified across public and internal services.

Happy to help test prereleases.

@erdelmaero commented on GitHub (Jun 2, 2026): +1 on this — would let us collapse a duplicated piece of our stack. We currently *do* use netbird-proxy for public service exposure and it's been great there. The gap is on the internal side: any service that should only be reachable from inside the mesh still goes through a separate Traefik instance we maintain ourselves. The pattern is: - service runs in our k8s cluster, no public DNS A record, no public IP - internal Traefik handles TLS termination (wildcard LE cert via DNS-01, managed by cert-manager), forward-auth via oauth2-proxy, host-based routing - the NetBird DNS we serve to mesh peers points to that Traefik's LB IP - peer hits e.g. `argocd.contoso.com` → Traefik → backend pod It works, but we're effectively maintaining two reverse proxies for what is conceptually one capability — "give peers a friendly hostname, terminate TLS, optionally gate with SSO". The reverse-proxy already does all that for public services. For internal-only services, all we want is for it to: - not require a public DNS A record / publicly resolvable hostname for each service (DNS-01 wildcard already covers TLS; the per-host A record only exists today to satisfy the public-exposure assumption) - run on a peer inside the mesh rather than the public exposure VM I think the underlying need — NetBird as ZTN + an internal reverse proxy in front of mesh-only services — is a very common architecture. Today users either do what we do (separate reverse proxy + NetBird DNS pointing at it), or fall back to bare IPs + remembering port numbers. Both are worse than having this in one product. @chadillac's sketch a few comments up matches our case almost exactly. The one thing we'd most want layered on top is the same per-service group ACLs the public reverse proxy already has, so we can keep the SSO / per-group access model unified across public and internal services. Happy to help test prereleases.

saavagebueno commented

2026-08-05 01:31:27 -04:00

@kgrotel commented on GitHub (Jul 18, 2026):

Why not just use BYOP (Bring your own proxy) deploy it on a Netbird Node, let it use a Netbird DNS Zone and you are done .. i even created a Netbird Operator for Kubernetes to deploy that Proxy .. works like a charm

@erdelmaero you seem to have similar setup we have just we use ciliumLB thus checkout -> https://github.com/ccbash/netbird-operator
would be great to get some feedback on it anyway

@kgrotel commented on GitHub (Jul 18, 2026): Why not just use BYOP (Bring your own proxy) deploy it on a Netbird Node, let it use a Netbird DNS Zone and you are done .. i even created a Netbird Operator for Kubernetes to deploy that Proxy .. works like a charm @erdelmaero you seem to have similar setup we have just we use ciliumLB thus checkout -> https://github.com/ccbash/netbird-operator would be great to get some feedback on it anyway

saavagebueno commented

2026-08-05 01:31:27 -04:00

@timthelion commented on GitHub (Jul 18, 2026):

@kgrotel that only gets you half way to what we want. That lets you expose a service on a URL. It wouldn't let you use netbird for fine grained access to services. Imagine you have five services on one server and you want separate ACLs for each one.

@timthelion commented on GitHub (Jul 18, 2026): @kgrotel that only gets you half way to what we want. That lets you expose a service on a URL. It wouldn't let you use netbird for fine grained access to services. Imagine you have five services on one server and you want separate ACLs for each one.

saavagebueno commented

2026-08-05 01:31:28 -04:00

@kgrotel commented on GitHub (Jul 19, 2026):

@timthelion it actually does .. using NetBird reverse proxy it registers in the control plane and supports policies assigned via groups for each exposed service it even shows access logs

@kgrotel commented on GitHub (Jul 19, 2026): @timthelion it actually does .. using NetBird reverse proxy it registers in the control plane and supports policies assigned via groups for each exposed service it even shows access logs

saavagebueno commented

2026-08-05 01:31:28 -04:00

@timthelion commented on GitHub (Jul 19, 2026):

@kgrotel um 😅. Take another look at the title of this issue. It says "internal". What I think everyone here wants, is to be able to do just that without creating an externally exposed URL.

@timthelion commented on GitHub (Jul 19, 2026): @kgrotel um 😅. Take another look at the title of this issue. It says "internal". What I think everyone here wants, is to be able to do just that without creating an externally exposed URL.

saavagebueno commented

2026-08-05 01:31:28 -04:00

@DjSni commented on GitHub (Jul 19, 2026):

@timthelion it actually does .. using NetBird reverse proxy it registers in the control plane and supports policies assigned via groups for each exposed service it even shows access logs

@kgrotel um 😅. Take another look at the title of this issue. It says "internal". What I think everyone here wants, is to be able to do just that without creating an externally exposed URL.

Well, to put it simply, we want it to be possible to use internal domains like myhome.lab, and for them to be accessible only through the Netbird reverse proxy, with all ACLs in place.
That way, I can just go to app.myhome.lab and see my app.

@DjSni commented on GitHub (Jul 19, 2026): > [@timthelion](https://github.com/timthelion) it actually does .. using NetBird reverse proxy it registers in the control plane and supports policies assigned via groups for each exposed service it even shows access logs > [@kgrotel](https://github.com/kgrotel) um 😅. Take another look at the title of this issue. It says "internal". What I think everyone here wants, is to be able to do just that without creating an externally exposed URL. Well, to put it simply, we want it to be possible to use internal domains like myhome.lab, and for them to be accessible only through the Netbird reverse proxy, with all ACLs in place. That way, I can just go to app.myhome.lab and see my app.

saavagebueno commented

2026-08-05 01:31:28 -04:00

@syorito-hatsuki commented on GitHub (Jul 19, 2026):

@timthelion it actually does .. using NetBird reverse proxy it registers in the control plane and supports policies assigned via groups for each exposed service it even shows access logs

@kgrotel um 😅. Take another look at the title of this issue. It says "internal". What I think everyone here wants, is to be able to do just that without creating an externally exposed URL.

Well, to put it simply, we want it to be possible to use internal domains like myhome.lab, and for them to be accessible only through the Netbird reverse proxy, with all ACLs in place. That way, I can just go to app.myhome.lab and see my app.

And it no need to exact be .lan, it can be normal domain with wildcard CA but subdomains goes first to NetBird DNS + Internal Proxy instead of public DNS and then to Proxy (at least that how I build it on Kubernates 👀)

@syorito-hatsuki commented on GitHub (Jul 19, 2026): > > [@timthelion](https://github.com/timthelion) it actually does .. using NetBird reverse proxy it registers in the control plane and supports policies assigned via groups for each exposed service it even shows access logs > > > [@kgrotel](https://github.com/kgrotel) um 😅. Take another look at the title of this issue. It says "internal". What I think everyone here wants, is to be able to do just that without creating an externally exposed URL. > > Well, to put it simply, we want it to be possible to use internal domains like myhome.lab, and for them to be accessible only through the Netbird reverse proxy, with all ACLs in place. That way, I can just go to app.myhome.lab and see my app. And it no need to exact be .lan, it can be normal domain with wildcard CA but subdomains goes first to NetBird DNS + Internal Proxy instead of public DNS and then to Proxy (at least that how I build it on Kubernates 👀)

saavagebueno commented

2026-08-05 01:31:28 -04:00

@WirtsLegs commented on GitHub (Jul 23, 2026):

yeah in my case what I'm hoping for is the ability to do a split basically, this would be the ideal but

Say I own example.com
I have 5 services, a.example.com, b.example.com, c.example.com, d.example.com, e.example.com

I want a.example.com and b.example.com to be accessible from the open internet (current reverse proxy feature), but also from within the netbird mesh, so clients connected aren't having their requests routed out onto the internet to the reverse proxy that's handling external requests. In both public and internal access cases I want to be able to optionally do auth and have fine grained control on who can access what and optionally include header values based on that auth. In this case the DNS would be split brain and ideally someone connected to the mesh is served a mesh address when they do a request for a.example.com and not the public record.

Then I want c.example.com, d.example.com, and e.example.com to ONLY be accessible to people that are connected to the mesh, not allowing public access. Further I want to be able to apply all the same fine grained control and adding header values etc for these services based on netbird groups/users etc.

@WirtsLegs commented on GitHub (Jul 23, 2026): yeah in my case what I'm hoping for is the ability to do a split basically, this would be the ideal but Say I own example.com I have 5 services, a.example.com, b.example.com, c.example.com, d.example.com, e.example.com I want a.example.com and b.example.com to be accessible from the open internet (current reverse proxy feature), but also from within the netbird mesh, so clients connected aren't having their requests routed out onto the internet to the reverse proxy that's handling external requests. In both public and internal access cases I want to be able to optionally do auth and have fine grained control on who can access what and optionally include header values based on that auth. In this case the DNS would be split brain and ideally someone connected to the mesh is served a mesh address when they do a request for a.example.com and not the public record. Then I want c.example.com, d.example.com, and e.example.com to ONLY be accessible to people that are connected to the mesh, not allowing public access. Further I want to be able to apply all the same fine grained control and adding header values etc for these services based on netbird groups/users etc.

Sign in to join this conversation.

Branches Tags

main

claude/agent-network-test-cases-p743vw

android/gui-integration

revert/component-types

feat-post_quantum_ml_kem

ice-stun-wg-demux

dependabot/npm_and_yarn/proxy/web/npm_and_yarn-b39864987c

agent-network-setup-poc

dependabot/go_modules/aws-sdk-8f849ebaed

dependabot/github_actions/actions-a940c7c866

dependabot/go_modules/otel-e34c790afd

dependabot/go_modules/testcontainers-de325c0dd6

dependabot/go_modules/wireguard-dbd6b95108

dependabot/go_modules/pion-5f703e1eca

dependabot/go_modules/gorm-2271c8195b

fix-login-needed-check

dependabot/go_modules/google.golang.org/grpc-1.82.1

fix/ui-gtk3-support

enterprise-traefik-and-migration-fixes

disambiguate_p2p_metrics

revert/component-types-hookup

embedded-vnc

feature/ios-ssh

docs/agent-network-docs-update

dependabot/go_modules/github.com/aws/aws-sdk-go-v2/service/s3-1.106.3

dependabot/go_modules/github.com/pion/stun/v3-3.1.5

fix-ssh-authorized-users-multi-rule

peer-acl-multi-source

reverse-proxy-crowdsec-appsec

reverse-proxy-allow-match-or

client-local-metrics

lazy-conn-per-peer

lazy-conn-rosenpass

dependabot/go_modules/github.com/gopacket/gopacket-1.7.0

dependabot/go_modules/goauthentik.io/api/v3-3.2026050.6

dependabot/go_modules/github.com/pires/go-proxyproto-0.15.0

dependabot/go_modules/github.com/jackc/pgx/v5-5.10.0

dependabot/go_modules/github.com/oapi-codegen/runtime-1.6.0

dependabot/go_modules/github.com/eko/gocache/lib/v4-4.2.4

dependabot/go_modules/github.com/pkg/sftp-1.13.11

dependabot/go_modules/github.com/coreos/go-oidc/v3-3.20.0

ssh-windows-privilege-check

fix/explicit-cors-handling

fix/remove-math-rand

test/gui-memory-leak-fix

fix/ui-status-dispatch

install-script-ui-dependencies

fix/grpc-get-network-map

fix/subscribe-status-coalesce

fix/tray-menu-item-leak

fix/windows-tray-race

feature/changeset

worktree-dns-route-qtype-fallthrough

mdm_integration

mlsmaycon-patch-2

feat/agent-network-ollama

proxy-tunnel-cache-ttl-env

coderabbitai/utg/1e5b0a5

grpc-acl

test/battery-drain

components-impl-drop-indexes-use-xids-no-resource-policy-map

fix/nmap-relevant-groups

e2e-guardrail-blocks-unselected-model

fix/lazyconn-cold-start-allowed-ips

vertex-guardrails-model-access-e2e

add-atomic-cache-ops

refactor/relay-foreign-cache

ci/trigger-release-tests

feature/kimi-3-agent-networks-dns-warmup

feature/dns-lazy-conn-warmup

daemon-ipc-acl

feature/ui-translation-key-parity-check

refactor/relay-foreign-cache-tests

fix/lazyconn-idle-keep-wg-peer

dmitri-propagate-auth-grant-types-on-combined

0.74.7-branch

diagnose-empty-vs-corrupt-state

windows-sleep-detector

fix/cli-up-wait-for-daemon

rp_key_persistency

feature/native-grpc

0.74.6-branch

0.74.6-branch-sync

0.74.5-branch-sync

0.74.4-branch

fix/remove-stale-peers-removal

fix/remove-stale-proxy-logic

fix/nsis-preserve-autostart-on-upgrade

refactor/peer-event-bus

dependabot/go_modules/goauthentik.io/api/v3-3.2026050.3

dependabot/go_modules/github.com/pkg/sftp-1.13.10

components-impl-drop-indexes

fix-reset-aggregation-window-flake

dependabot/go_modules/github.com/pion/dtls/v3-3.1.5

0.74.x

fix/relay-states-lock

update-process-pkg

update-gopsutil-v4

fix/relay_states_lock

increase-sysinfo-timeout

dependabot/go_modules/github.com/Azure/go-ntlmssp-0.1.1

dependabot/go_modules/github.com/eko/gocache/store/redis/v4-4.2.6

dependabot/go_modules/github.com/eko/gocache/lib/v4-4.2.3

fix/fail-to-create-upnp-port-mapping-on-opnsense-firewall

0.74.3-branch

fix/routeselector-atomic-exit-node

netmap_progressive_alignment

nmap/components-impl

dependabot/go_modules/github.com/jackc/pgx/v5-5.9.2

dependabot/go_modules/github.com/oapi-codegen/runtime-1.4.2

dependabot/go_modules/github.com/gopacket/gopacket-1.6.1

dependabot/go_modules/github.com/coreos/go-oidc/v3-3.19.0

dependabot/go_modules/github.com/pires/go-proxyproto-0.12.0

fix/signal-watchdog-sync-stop

docs/agent-network

test/affected-logic

fix/revert-ice-filter

refactor/simplify-affected-peers

pascal-filter-policies-by-direction

claude/lock-contention-peer-connect-g8t6au

dmitri-filter-policies-by-direction

refactor/migrate-profiles-to-go

profile-bindings-ios

fix/skip-restart-unchanged-route

fix/mgmt-cache-async-resolve

refactor/wails-update-105

client_lifetime_serialization_refactor

fix/browser-ssh-2

fix/ipv6-and-netstack-accept-loop

fix/browser-ssh

profile-id-name-test

refactor/mgmt-bootstrap

feat/getting-started-unified-wizard

socket-grpc-permissions

fix/mysql-index-migration

windows-dns-firewall

tests/enable-race-on-tests

ui-refactor-gtk3

feature/affected-peers-grpc

profile-id

lazyconn-first-packet-fix-v2

claude/focused-gates-VMTgb

ui-tray-linux-leftclick

fix/ctx-enrichment

daemon-owner

feature/android-client-ssh

worktree-accept-ra-forwarding

nmap/combined-deploy

task/align_protobuff_toolset

feature/session-extend

add-json-yaml-flags

refactor/ephemeral-cleanup

claude/webtransport-relay-wasm-mUjY9

claude/vnc-udp-feasibility-6KB1U

fix/wgport-config

e2e-windows-dns-combined

fix/login-cmd-root-flags

feat/reseller-openapi-spec

github-issue-resolver

add-steamos-support

fix-darwin-uninstaller

flutter-test

ci/freebsd-pkg-bootstrap

cached-serial-check-on-sync

fix-mgmt-cache-bypass-overlay

revert-easyjson-5938

revert-ice-5820

revert-firewalld-5928

refactor/permissions-manager

revert-dns-5935-systemd-resolved

revert-dns-5935-5945

revert-dns-5945-mgmt-cache

feature/log-most-busy-peers

prototype/ui-wails

coderabbitai/utg/8ae8f20

feature/use-peer-fqdn-on-https

release/0.68.3

add-slack-channel

claude/rdp-token-passthrough-eNcqW

transparent-proxy

fix/macos-stale-route-eexist

crowdsec-selfhosted

fix/remove-otel-units

entire/checkpoints/v1

fix/getting-started

feat/static-connectors-combined-server

feature/use-local-keys-embedded

feature/fleetdm

set-env-only-if-not-fork

feature/expose-has-channel

fix/connection-status-race

fix/filter-cgnat-cni-ice-candidates

feature/check-cert-locker-before-acme

test/proxy-fixes

test/proxy-mtu

prototype/ui-tauri

test/proxy-speed

fix-reused-ports

feat/migrate-to-embedded-idp

feature/add-serial-to-proxy-merged

deploy/proxy-serial

test/connection

feature/disable-legacy-port

feature/flag-to-disable-legacy-port

test/perftest

fix/http-redirect

poc-token-command

dn-reverse-proxy

prototype/reverse-proxy-rename

prototype/reverse-proxy-logs-pagination

feature/client-metrics

prototype/reverse-proxy-clusters

debug-dns-route

fix/win-dns-batch

add-extra-route-logs

job-stream-notify-disconnection-eof

deploy/secrets-manager

trigger-proxy-update

bug/update-ios-client-code-build-tags

sync-client-netmap-serial

log/conn-disconn

nmap/compaction-deploy

ci-win-test

feature/disk-encryption-check

wasm-debug

swap-dns-prio

fix/dex-config

feature/migrate-auto-groups-to-table

nmap/compaction

dex-nocgo-stub

feature/exclude-terraform-from-rate-limiting

test-freebsd

retries-refactor

coderabbitai/docstrings/b7e98ac

feat/integrate-zitadel

bug/ios-hanging-reconection

zitadel-idp

feat/network-map-serial

refactor/get-account-no-users

feat/auto-upgrade

feature/report-high-pat-id

feature/temporary-access-for-resource

fix/nmap-fwrules

dont-restart-dns

prototype/ui

update-gomobile

go-dns-for-ice

wasm-ldflags

test-ldflags

wasmbuild-test

feature/networks-s2s

vk/compare-nmaps

dbg/bothmaps

reorder-dns-shutdown

fix/relay-reconnection-race

fix/nmap-exitnodes

vk/debug/nmap-both

move-licensed-code

feat/better-daemon-connection-lost-message

feat/auto-update-2

test/timings

refactor/getaccount-raw

tests/nmap-getaccount

refactor/nmap

refactor/nmap-limit-buffer

feature/detect-mac-wakeup

feature/extract-modules

quick-setings

feat/sync-limiter

feature/store-cache-impl

fix-install-version

feature/store-metrics

feature/metrics-on-store

feature/use-gorm-cache

loadtest-signal

unsymmetrical-squash

refactor/reducate-signaling

test/update-reduce

feature/store-cache

feature/remote-debug

cli-ws-proxy-backend-addr

feat/mgmt-map-serial

snyk-fix-d9d0081a4c7f9137bdb59d0d50a141a2

snyk-fix-7415cea5a11acd66753540ca2c598c63

job-yml-update

feature/android-allow-selecting-routes

fix/up-sequence

fix/dns-hash-update

snyk-fix-967adae9863f17f108ce8948d9117b8d

log/getaccount-by-peer

signal-suppressor

dns-exit-node

feature/auto-updates

feature/cache-srv-key

merged-fixes

fix/missed-offers-and-debug

debug-and-fixes

poc-wasm-clean-backend-s2s

test/remote-debug

debug-api

fix/remove-gpo-if-empty

fix/test-freebsd

fix/mysql-setup

fix/remove-logout-btn

handle-existing-domain-user

chore/unify-domain-validation

snyk-fix-c5fafc8a50ce1f29046e25a1fc346185

feat/profile-edit-btn

snyk-fix-a54966211e18d4cf67e5a2757cc006d1

log-short-id

feat/logout-ephemeral

log-checks

batch-wg-ops

nb-interface-default

feat/aws-integration

add/race-test

feature/relay-feature-versioning

fix/systemd-service-logs

poc/preprocessed-map

add-account-onboarding

bind-ipv6

fix/merge-main

logs/peerlogs-addpeer

feature/net-297-network-migration

feature/support-skip-auto-apply-exit-node-routes

set-cmd

set-command-with-cursor

feature/limit-update-channel

stop-using-locking-share

feature/poc-lazy-detection

feature/net-248-removal-of-sync-mutex-locks

test/multiple-peer-logging

preresolve

add-ns-punnycode-support

apply-routes-early

windows-search-domains

fix/connecting-route-filter

feature/management/rest-client/impersonate

debug-local-records

resource-fields-snake-case

test/grpc-rate-limit

traffic-correlation-policy

feature/rest-client-options

feat/events-metrics

feature/buf-cli

test/add-ratelimiter

test/remove-write-lock-on-add-peer

fix/add-peer-semaphore

feature/users-roles-endpoint

mlsmaycon-patch-1

debug-user-role

chore/primary-key-on-networks

feature/update-account-peers-buffer-startup

remove-ubuntu2004-runners

refactor/permissions-no-pat-allowed

ref/logrus-factory

use-conntrack-zone

deploy/permissions-account

feature/lazy-connection-idle

ref/improve-test-cov

restore-pr-3440

test/increase-grpc-timeouts

feat/buffer-account-peers-update

test/networkmapgeneration-changes

feature/base-manager

feature/flow-receiver

chore/benchmark-with-large-runner

refactor/handshake-initiator

client/ui-update-systray-icons

userspace-router

wgwatcher-test

output-if-key-already-exists

fix/relay-reconnection

feature/port-forwarding-client-codecleaning

detached2

test/callbacks-nil-iceconninfo

refactor/optimize-peer-expiration

enable-udp-port-for-docker-template

fix/relay-update

feature/apply-posture-netmap

fix/group-update-existing-resource

conntrack-stats

upgrade-okta-sdk

multi-price

test/conn-stat

set-min-parallel-tests-for-management

dns-interceptor

debug-dns

router-dns

add-static-system-info

debug-0.29.4

debug-0.33.0

account-refactoring

relay/2800_quic

route-get-account-refactoring

test/seed-random-routes

feature/get-account-refactoring

test/reconnect-race-condition

refactor/get-account-usage

feature/add-session-id-to-update-channel

improve-ipv4conn

fix/async-pion-event-handling

debug

add-offload

feature/validate-group-association-debug

fix/limit-conn-for-sqlite

test/engine-iface

test/transaction-for-jwt-sync

fix/engine-stop-in-foreground

feature/add-mysql-support

test-migration

refactor/header-size-values

relay/eliminate-gob

test/signal-dispatcher-with-relay

relay/debug

validate-icon

feature/ipv6-support

use-pre-expanded-peers-map

feature/use-signal-dispatcher

validate/peer-status

add-read-write-times

fix/sync-peer-race

feature/relay-status

netmap

evaluate/network-map-hash

fix/lower-dns-resolve-interval-on-fail

feature/relay

fix/go-mod-version

upgrade-nftables

synology-userspace-mode

fix/use-ip-for-default-routes-on-darwin

fix/proxy_close

enable-release-workflow-on-pr

deploy/peer-performance

feature/permanent-turn

feature/permanent-turn-proxy

deploy/posture-check-sqlite

feature/optimize_sqlite_save

debug-ios-behavior

fix/delete-route-only-after-adding

tshoot/windows-logger

remove-new-routing

refactor/eliminate-repo-dependency

add-arm-to-ci

refactor-demo-account-object

test/abc2

test/abc

send-ssh-rosenpass-config-meta

refactor-demo

ensure-schedule-never-runs-non-positive

feature/peer-validator-groupmgm

feature/peer-validator-fix

fix/include-active-dashboard-users

fix/handle-canceling-schedule

fix/geo-download

debug-google-workspace

yury/resolve-ip-to-location

feature/extend-sysinfo

sqlite-async-peer-status

yury/add-postgresql-store

fix/route

test-build

posture-checks-poc

debug-keycloak-idp

poc/netstack

for-pascal-tmp

peer-logout-management

manual-peer-logout

detached

chore/refactor-management

test/dns-bind

fix/enforce-acl-for-containers

yury/use-sync-map-in-updatechannel

fix/events-key-handling

filter-cache-on-load-account

fix/user-expiration

handle-user-context-cancellation

nb-client-k8s-statefulset

fake-addr

fix/iptables_in_docker

ebpf-debug

update-getting-started-flow-use-postgres

fix/peer_list_notification

feature/device-authentication-with-client-secret

feature/keep_alive

feat-groups-from-jwt

separate_proxy_from_wgconfig

fix/wg_conn

wg_conn_fix

wg_bind_parallel_processing

fix-rollback-get-acls

proxy_cfg_cleanup

performance-improvement-rego

update-lock-log-level

feat-client-side-acl

refactor/move_grpcserver_logic_to_account_manager

feature/event-storage

feature/update-idp-redeeming-invite

feature/api-peer-info

return-groupminimum-setupkey

feature/interface-bind

documentation_enhancement

fix-peer-registration

ssh

users_cache

pass-client-caller

client_caller_type

revert-283-feat-fix-windows-installer

periodic-peer-updates

ebpf

braginini/wasm

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: DYNR/netbird#11880