Inbound SSH session fails to complete

[Rick_H]

This problem has me completely stumped. I have a FGT100D, 4.3p7, deployed in transparent bridge mode (VDOMs enabled, if it matters). I am using the FGT primarily as a webfilter, so it is sitting in front of the inside interface on my firewall. All " outbound" traffic traverses the FGT normally, but I have an inbound connection that fails to complete the TCP 3-way handshake. Here are the particulars: I have a host running an SSH server on the inside. The SSH host has a static NAT on the outside of the firewall, which translates a public IP to the private IP of the inside host. A policy is in place allowing all traffic entering the firewall-facing port (wan2) to exit the inside-facing port (port16). Only two interfaces are in this VDOM. By running packet captures on the FGT I am able to see SYN packets destined for the SSH host enter the FGT on wan2 and exit port16. I am also able to see the SYN/ACK packet from the SSH host enter port16, but never exit wan2. A review of the Traffic log shows that the SYN/ACK packet that entered port16 is denied because " no session matched." I have confirmed that I am able to make " outbound" SSH connections without a problem. Any ideas on why the stateful inspection engine would not recognize the earlier part of the SSH session?

[pchechani_FTNT]

create a policy from Port16 as source and wan2 as destination. That will allow packet to pass thru from port 16 to wan2.

[Rick_H]

Even though it should not be necessary due to stateful inspection, I do already have a policy configured to allow this specific traffic to flow from port16 to wan2. The policies are written like this: wan2 -> port16 ssh_sources ssh_host always any port16 -> wan2 ssh_host ssh_sources always any I have also reconfigured the services from " any" to the specific set of services needed (SSH and HTTPS) with the same result. As mentioned in my previous post, all outbound traffic (sourced from hosts facing port16) flows and is allowed as expected.

[emnoc]

Have you ran' d the diag debug flow? Debugging flow with the correct diagnostic commands is very helpful in tracking why things fails. It would also ensure you have NO other fwpolicies that might be set that globally drops ssh for example. Run the diag debug flow and I will bet you the issue will be made clear as to why your session is drop. Here' s a quick guide; http://www.lebleuet.net/how-to-run-a-debug-on-a-fortinet-firewall?lang=en