Gitea web server hijacked primary IP?

TrueNAS General
,
1

I need to get Gitea to use standard ports (22/443) while also allowing TrueNAS to operate on these ports.

TrueNAS is at 172.23.7.13. I was able to tell the web server to bind to this address instead of 0.0.0.0:443, but can’t figure out how to pass ListenAddress to sshd, so I simply changed it to port 2222 (less than ideal).

Then, in the Gitea app settings, I set the WUI and SSH ports to 443 and 22, respectively, then set the Host IP on both to 172.23.7.16, which has been added as a secondary IP on TrueNAS.

This worked until I started configuring Gitea. Upon trying to add an LDAP authentication source, I lost access to TrueNAS. Navigating to 172.23.7.13 brought me to Gitea. Somehow, Gitea, in it’s container, was able to hijack traffic to 172.23.7.13:443.

After logging into TrueNAS via ssh (2222), i was able to stop the gitea container and restore TrueNAS WUI access, but now I’m stuck.

Docker inspect shows that he PortBindings are correct, does it not?

        "NetworkMode": "ix-internal-gitea-gitea-net",
        "PortBindings": {
            "22/tcp": [
                {
                    "HostIp": "172.23.7.16",
                    "HostPort": "22"
                }
            ],
            "443/tcp": [
                {
                    "HostIp": "172.23.7.16",
                    "HostPort": "443"
                }
            ]
        },

I’m not quite sure what else I can do. I’m not sure if this is a TrueNAS problem or a Docker problem, but I can set up Gitea on Podman with zero issues. Using Podman is possible, but less than ideal. I’d much rather have my git repositories in TrueNAS where they are immediately available from backups rather than being buried in a backup image of a virtual disk.

2

Setting the host IP only sets it for ingress to the container. Egress will still use the host’s primary IP and gateway.

3

You cannot have both TN and an a Docker app using the same ports.
(Only if you use a Macvlan/Ipvlan in Docker, so the app truly has a separate IP address).

Best practice is to move TN from port 443 to something else and in this case, move sshd to a different port also.

“Less than ideal”? They are just ports!

4

Better practice yet would be to put both Gitea and TrueNAS behind a reverse proxy and have that listen on 80/443. I describe this using NPM here:

Doesn’t address SSH though.

5

Not sure if we’re comparing apples to apples. From what I read, the way to have a per-app IP address is to create a bridge, move the primary IP to the bridge, then add additional IPs. Then in the app config, you specify the Host IP to use.

2 problems with this that I’ve run into… the host (truenas) wants all it’s services to bind to every address and provides no mechanism to limit sshd. The other problem, as you pointed out, is that the Host IP sets the ingress, which is what we’re talking about. Ingress to port 443 on the IP address used by the TrueNAS somehow ended up going to the Gitea app.

The solution, of course, is to us the MACVLAN network like Podman does, but apparently this isn’t supported without mucking around in the CLI, which I’m fine with at home, but is problematic in a production environment.

Another, less ideal solution, is to use alternat port numbers. Again, this is fine when someone wants to live dangerously and expose their homelab to the world, but in a production environment, this is a non-starter. We make extensive use of RFC1918 addresses and DNS specifically so we don’t have to commit hundreds or even thousands of alternate port numbers to memory just so we can get our work done.