I feel like I'm doing everything right... but something's not working.
We have a DevOps Server which provides SSH access for GIT operations. I've created a DNAT rule for it: from InternetV4 -> SSH -> External IP to change the destination to the DevOps internal IP.
This work for external connections. But anyone trying to access the server over SSH from our LAN is having issues because that rule alone doesn't provide the loopback required.
So I've also added the following FullNAT:
- from LAN -> SSH -> External IP- change destination: DevOps internal IP- change source: UTM internal IP
Now... weird thing is that this PARTIALLY works - i.e. if I start SSH <our DevOps public URL> I'm going to get the expected server SHA identification fingerprint (before it's marked as trusted).
However, actually trying to USE the service (via GIT CLONE, for example) returns:
Unable to negotiate with <Public DevOps IP> port 22: no matching host key type found. Their offer: ssh-rsafatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.
So... Full NAT isn't working as expected in this case. Any idea what's missing?
PS. I could instruct users to use the internal server DNS name, rather than the public DNS... but everyone's used to using the public URL it's probably a hassle to have people switch to one or the other. Additionally it might be annoying if users sometimes work remotely and sometimes work at the office.
PPS. Whilst our UTM is also our DNS I cannot really map the public DevOps DNS directly to the internal IP via a static mapping. Too many things use HTTPS and I'm relying on the LE certificate which is handled by the UTM itself.
Nevermind... turns out... it's a DevOps issue.
Just found this and it resolves the issues... Full NAT is working fine.https://stackoverflow.com/questions/69875520/unable-to-negotiate-with-40-74-28-9-port-22-no-matching-host-key-type-found-th
I must have some older version of SSH installed on my home PC, making my test results misleading.