NAT within LAN issue

[sh1212]

I'm having an issue that I can't seem to get resolved resulting in SSH timeouts.

I have a rule in DNS Resolver that converts all *.local.domain.name to a virtual IP 192.163.1.253. HAProxy is used to direct to correct internal server for ports 443 and 80 based on subdomain. This is all working perfectly.

One of my servers on LAN I'm wanting to run a git server with SSH access. I've setup a NAT rule on LAN that redirects virtual IP:22 to (git server IP):(git ssh port). I even have a firewall rule for PASS IP any, Port any to git server IP:git ssh port to log traffic.

If I

ssh git-server-ip -p git-server-port

it attempts to connect (but oddly I see nothing logged by the firewall rule)

If I

ssh internal-domain-for-virtual-ip

then it just says connection timed out, but in the firewall log I can see traffic from my local host to the expected ip/port.

Where am I going wrong? Is there a better way to be doing this that with a NAT rule?

[johnpoz]

@sh1212 said in NAT within LAN issue:

ssh git-server-ip -p git-server-port
it attempts to connect (but oddly I see nothing logged by the firewall rule)

Why would you think that would hit pfsense.. Traffic on the same lan doesn't talk to pfsense.

Is there a better way to be doing this that with a NAT rule?

Why are you trying to use nat reflection internally? Just hit whatever you want to hit by its actual IP set your local dns resolving the actual IP.

[sh1212]

Why are you trying to use nat reflection internally? Just hit whatever you want to hit by its actual IP set your local dns resolving the actual IP.

I have a variety of sites that are publicly accessible via mydomain.com. These work by NAT from WAN to virtual IP which is then redirected by HAProxy. All these work off the same LetsEncrypt certificate. As I own this domain and its cert was being verified by LetsEncrypt it was trivial to have valid HTTPS within my own internal LAN using *.local.mydomain.com (no need to trust self-signed certs, CA, etc. It just works). Only issue is the lack of SSH using the same domain name.

Since the traffic via virtual IP was getting logged by firewall it seemed odd to me that the other traffic wasn't but that makes perfect sense as to why it wouldn't be, thank you.

[johnpoz]

I have never tried bouncing ssh off haproxy.. But you should be able to do it - quick google finds this

https://www.haproxy.com/blog/route-ssh-connections-with-haproxy/

But looks like you need to use the "All solutions rely on the ssh command’s ProxyCommand field"

Prob be just easier to when you want to ssh to the box, use the local IP or just a different fqdn for ssh that points to the local IP. Since there little need for any acme cert to be leveraged with ssh connection.

hostname.differentlocaldomain.tld maybe something like hostname.ssh.lan

[sh1212]

Man do I feel dumb. I had already tried using HAProxy to but was using ACL's to choose the correct backend. I changed it to just using a default backend and now it is working as expected.

One issue that I can't get to resolve correctly is that I can't use any ACLs based on subdomain with TCP mode. This simply means that it is currently setup so that any requests to *.internal.mydomain.com:22 get routed to the git server. This isn't a huge issue for me since this is for internal use only and I don't have any other cases where this is needed (normally I'd just SSH via hostname).

Thanks @johnpoz for pointing me in a direction to find a solution that works for me.

For future reference to any that need to do this:

Frontend: git_ssh_fe
Listens on virtual IP, port 22
Type: tcp
ACL/Actions - none
Default backend: git_ssh_be

Backend: git_ssh_be
Server list points to ip:port of internal git server

[johnpoz]

My understanding from the breeze over I did of that article linked to - is you could send it to different servers based on name - but you need to use the proxycommand from your ssh client.. Which seems like more work then just using a different local domain or IP ;) and not bouncing off the proxy.

That could come in handy if all your clients that wanted to talk to different ssh servers were outside your network vs doing a reflection connection from the local netework.