Multiple IP address for gitlab get problem on LFS server

Hi guy, hope you are all good.

I encountered an issue while using GitLab and am unsure how to resolve it. I hope someone can provide a solution. I have deployed a GitLab instance using Docker on my personal computer running Ubuntu. This computer is connected to two different local networks, each with its own subnet. Consequently, my server has two IP addresses, leading to a problem with accessing the LFS (Large File Storage) server.

When I set the external_url in the gitlab.rb file to the LAN1 address, devices on LAN2 can access GitLab normally but cannot connect to the LFS server. Conversely, if I set it to LAN2, devices on LAN1 cannot access GitLab. LAN1 is a conventional local network, while LAN2 is a LAN created using ZerotierOne for internal network tunneling.

Currently, I am continuously reconfiguring the server to alleviate the issue, but I must find a permanent solution.

the follow picture is showing the problem what I have：

285728323-efbeccda-d2b1-4818-b909-575042f668e71355×321 39.6 KB

In the scenario depicted, I aim to access GitLab and pull branches using the 10.x.x.x network. However, GitLab is currently configured with an address in the 192.x.x.x network. While regular Git repositories are accessible without issues, there are address-related problems when interacting with the LFS (Large File Storage) repository.

I need devices from two local networks to be able to access (actually, my server is in three networks, but I simplified it for clarity). Access to LFS is crucial. Please provide me with some solutions or suggestions. Thank you very much!

The proper way to do this is assign a hostname to an IP address by using DNS (or if no DNS server configure the hosts file on each of the machines to resolve the hostname to the IP), and then use routing to route between different subnets. Trying to do what you are doing isn’t going to work.

You should only be using one IP for your server. The problem you have is packets come in on one interface but due to lack of routing, they go out of the one that has the default route attached. Since this isn’t the gateway for the LAN2 interface you then get problems.

Ideally, LAN2 should be using the IP of the Gitlab server from LAN1. LAN2 should then have routing to tell it how to connect to LAN1. The same applies to using it over ZeroTier as well.

It’s possible to use split-zone DNS by resolving a different IP for DNS depending on where the DNS query was received. So if the DNS query was on LAN1, it would respond with the IP for the gitlab server DNS entry in LAN1. And if the query is received from LAN2, it can resolve the DNS entry for LAN2. Either way, the external URL should be using a FQDN rather than configuring it with the IP.