[GH-ISSUE #6181] Git over HTTPS connection reset when accessing GitLab through NetBird reverse proxy on Windows #11560

Closed
opened 2026-08-05 01:30:02 -04:00 by saavagebueno · 2 comments
Owner

Originally created by @LsJason on GitHub (May 17, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/6181

Issue Summary

Some Windows development environments fail to clone GitLab repositories over HTTPS with a connection reset error when the GitLab URL is accessed through a NetBird reverse proxy / gateway path.

Example command:

git clone https://git.example.internal/group/project.git

Example errors:

fatal: unable to access 'https://git.example.internal/group/project.git/': Recv failure: Connection was reset

or:

OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to git.example.internal:443

Initial Assessment

This does not appear to be a GitLab repository permission issue or an incorrect username/password/token issue.

When the HTTPS connection reaches GitLab correctly, GitLab returns an authentication-related response, such as:

HTTP Basic: Access denied

or prompts for a username/token.

In the failing case, the request fails earlier during the TLS/HTTPS connection phase.

Observed Trigger

The issue is mainly observed when Git HTTPS traffic goes through an internal NetBird reverse proxy or gateway layer, for example:

Windows Git Client
  -> git.example.internal
  -> NetBird reverse proxy / gateway on port 443
  -> GitLab

Windows Git uses the Schannel TLS backend by default, and this path may result in:

Recv failure: Connection was reset

As a temporary workaround, switching Git to OpenSSL may allow the request to reach the GitLab authentication stage:

git config --global http.sslBackend openssl
git config --global http.version HTTP/1.1

However, this is not suitable as a long-term team-wide solution because every developer would need to apply the same local Git configuration.

Expected Behavior

Git over HTTPS should work through the NetBird reverse proxy / gateway without requiring each Windows user to change their local Git TLS backend or HTTP version.

A working long-term workaround is to avoid routing Git HTTPS traffic through the reverse proxy / gateway layer.

Instead, route the Git domain directly to the GitLab server inside the private network:

git.example.internal
  -> Internal DNS resolves directly to the GitLab server private IP
  -> GitLab server listens on local HTTPS port 443
  -> Local Nginx reverse proxies to the GitLab container/application

Example DNS result:

git.example.internal -> 192.168.0.10

Example local routing on the GitLab server:

443 -> 127.0.0.1:8080

Developers can continue using the same Git URL:

https://git.example.internal/group/project.git

but Git HTTPS traffic no longer passes through the problematic proxy/gateway layer.

Validation

After the DNS change, verify the resolved address:

nslookup git.example.internal

Expected result:

Address: 192.168.0.10

Then test cloning again:

git clone https://git.example.internal/group/project.git

If the result becomes:

HTTP Basic: Access denied

or Git prompts for a username/token, the HTTPS/network path is working correctly and the remaining issue is GitLab authentication.

Temporary Workaround

If the DNS or proxy adjustment cannot be completed immediately, Windows users can temporarily run:

git config --global http.sslBackend openssl
git config --global http.version HTTP/1.1

To restore the default Git configuration:

git config --global --unset-all http.sslBackend
git config --global --unset-all http.version

This workaround should not be considered the final team-wide solution.

Originally created by @LsJason on GitHub (May 17, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/6181 ## Issue Summary Some Windows development environments fail to clone GitLab repositories over HTTPS with a connection reset error when the GitLab URL is accessed through a NetBird reverse proxy / gateway path. Example command: ```powershell git clone https://git.example.internal/group/project.git ``` Example errors: ```text fatal: unable to access 'https://git.example.internal/group/project.git/': Recv failure: Connection was reset ``` or: ```text OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to git.example.internal:443 ``` ## Initial Assessment This does not appear to be a GitLab repository permission issue or an incorrect username/password/token issue. When the HTTPS connection reaches GitLab correctly, GitLab returns an authentication-related response, such as: ```text HTTP Basic: Access denied ``` or prompts for a username/token. In the failing case, the request fails earlier during the TLS/HTTPS connection phase. ## Observed Trigger The issue is mainly observed when Git HTTPS traffic goes through an internal NetBird reverse proxy or gateway layer, for example: ```text Windows Git Client -> git.example.internal -> NetBird reverse proxy / gateway on port 443 -> GitLab ``` Windows Git uses the Schannel TLS backend by default, and this path may result in: ```text Recv failure: Connection was reset ``` As a temporary workaround, switching Git to OpenSSL may allow the request to reach the GitLab authentication stage: ```powershell git config --global http.sslBackend openssl git config --global http.version HTTP/1.1 ``` However, this is not suitable as a long-term team-wide solution because every developer would need to apply the same local Git configuration. ## Expected Behavior Git over HTTPS should work through the NetBird reverse proxy / gateway without requiring each Windows user to change their local Git TLS backend or HTTP version. ## Recommended Direction / Workaround A working long-term workaround is to avoid routing Git HTTPS traffic through the reverse proxy / gateway layer. Instead, route the Git domain directly to the GitLab server inside the private network: ```text git.example.internal -> Internal DNS resolves directly to the GitLab server private IP -> GitLab server listens on local HTTPS port 443 -> Local Nginx reverse proxies to the GitLab container/application ``` Example DNS result: ```text git.example.internal -> 192.168.0.10 ``` Example local routing on the GitLab server: ```text 443 -> 127.0.0.1:8080 ``` Developers can continue using the same Git URL: ```text https://git.example.internal/group/project.git ``` but Git HTTPS traffic no longer passes through the problematic proxy/gateway layer. ## Validation After the DNS change, verify the resolved address: ```powershell nslookup git.example.internal ``` Expected result: ```text Address: 192.168.0.10 ``` Then test cloning again: ```powershell git clone https://git.example.internal/group/project.git ``` If the result becomes: ```text HTTP Basic: Access denied ``` or Git prompts for a username/token, the HTTPS/network path is working correctly and the remaining issue is GitLab authentication. ## Temporary Workaround If the DNS or proxy adjustment cannot be completed immediately, Windows users can temporarily run: ```powershell git config --global http.sslBackend openssl git config --global http.version HTTP/1.1 ``` To restore the default Git configuration: ```powershell git config --global --unset-all http.sslBackend git config --global --unset-all http.version ``` This workaround should not be considered the final team-wide solution.
Author
Owner

@linear-code[bot] commented on GitHub (May 17, 2026):

NET-1184

<!-- gh-comment-id:4469402639 --> @linear-code[bot] commented on GitHub (May 17, 2026): <!-- linear-linkback --> <p><a href="https://linear.app/netbird/issue/NET-1184">NET-1184</a></p>
Author
Owner

@jnfrati commented on GitHub (May 19, 2026):

Moving this to a discussion as per the new issue triage flow https://github.com/netbirdio/netbird/discussions/6074

<!-- gh-comment-id:4486170527 --> @jnfrati commented on GitHub (May 19, 2026): Moving this to a discussion as per the new issue triage flow https://github.com/netbirdio/netbird/discussions/6074
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11560