02-08-2025 03:42 PM
I’m trying create a configuration where a firewall with a single public IP address can forward incoming connections to an internal server. While this seems straightforward, I’m encountering issues and would appreciate any guidance.
The best documentation I've seen on this is:
Managing Firewall Threat Defense with Cloud-delivered Firewall Management Center in Cisco Security Cloud Control section Interfaces and Device Settings > Network Address Translation > Examples for NAT > Providing Access to an Inside Web Server (Static Auto NAT)
Setup Details:
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.3 FreeBSD-20240701
debug1: compat_banner: match: OpenSSH_9.3 FreeBSD-20240701 pat OpenSSH* compat 0x04000000
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.1 PKIX[13.5]
debug1: compat_banner: match: OpenSSH_9.1 PKIX[13.5] pat OpenSSH* compat 0x0400000
So not only am I not seeing the desired result, when I connect to port 22 I’m able to log into the FTD CLI via SSH from the Internet, which is not acceptable — I do not want infrastructure login ports exposed directly on the Internet under any circumstances.
Configuration Details:
Attached screenshots show the Access Policy rule and a copy of `show nat detail` output.
Question:
What am I missing in my NAT or firewall configuration that would prevent incoming connections from being properly forwarded to the internal SSH server? Any insights or suggestions would be greatly appreciated.
Solved! Go to Solution.
02-10-2025 10:24 AM
Makes sense the way you configured the NAT rule. Regarding port 22, it seems that you are allowing SSH to the device via its platform settings? You can check that by going into Devices > Platform Settings > Secure Shell. In case you find it enabled, please ensure that you don't need that access before turning it off. I don't believe cdFMC needs SSH as I think the ports required would be 443/tcp and 8305/tcp. Once that is removed port 22/tcp should start working for your custom NAT rule. Alternatively, if you happen to have another public IP you can use that one instead of using the public IP of the outside interface.
02-10-2025 04:28 AM
Please remove that rule and recreate it as a manual rule and make sure the translated port is set to port 2222 and the original port is set to 22.
02-10-2025 09:10 AM
Thank you for replying.
I have tried what you suggest here (also in screenshots)...
Interface Objects
Source interface objects: any (default)
Destination interface objects: OUTSIDEzone
Original Packet
Original source: Internal_SSH (host real IP: 10.3.3.140)
Original destination: Address (default) / [empty] (default)
Original Source Port: [empty] (default)
Original Destination Port: SSH (tcp/22)
Translated Packet
Translated Source: Destination Interface IP
Translated Destination: [empty] (default)
Translated Source Port: [empty] (default)
Translated Destination Port: SSHon2222 (tcp/2222)
And my result was timeouts connecting to 2222 from outside the firewall. Inside the firewall, tcpdump on the SSH server saw no packets arrive inbound.
02-10-2025 09:49 AM
I have found success! My settings are very different from what is given in the documentation (but they do seem logical according to the user interface):
Interface Objects
Source interface objects: OUTSIDEzone
Destination interface objects: INSIDEzone
Original Packet
Original source: any
Original destination: Source Interface IP
Original Source Port: [empty] (default)
Original Destination Port: SSHon2222 (tcp/2222)
Translated Packet
Translated Source: Destination Interface IP
Translated Destination: Internal_SSH (host:10.3.3.140)
Translated Source Port: [empty] (default)
Translated Destination Port: SSH (tcp/22)
Once I deployed this configuration I was immediately able to ssh -p 2222 <my public IP> ... however when I changed the "Original Destination Port" to 22, SSH connections on that port were not translated/forwarded to the internal host and I still connected directly to the FTD.
Any insights on how to (a) make connections to port 22 translate to an internal host and (b) stop the FTD from responding to SSH connections from the upstream-side?
Thank you!
02-10-2025 10:24 AM
Makes sense the way you configured the NAT rule. Regarding port 22, it seems that you are allowing SSH to the device via its platform settings? You can check that by going into Devices > Platform Settings > Secure Shell. In case you find it enabled, please ensure that you don't need that access before turning it off. I don't believe cdFMC needs SSH as I think the ports required would be 443/tcp and 8305/tcp. Once that is removed port 22/tcp should start working for your custom NAT rule. Alternatively, if you happen to have another public IP you can use that one instead of using the public IP of the outside interface.
02-10-2025 12:51 PM
Many thanks! I now remember enabling the SSH setting and after removing the OUTSIDEzone interface from the list the NAT works as intended. It all makes so much sense now. Thank you for taking the time to reply.
02-11-2025 01:22 AM
You are very welcome.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide