Can you provide more details of the rule you have created for this?
Assuming we are dealing with a standard scenario where the external interface is using a public IP address and the internal side is using a private range, passing traffic from public to private requires a rule where the source and destination zones are both configured as "external" (or whatever you have named your external/internet zone), the destination host value should then be an address object corresponding to the public IP address you want to use for this service and you then assign a redirect host using an address object configured with the IP address of the machine you actually want to SSH to.
The client application should then be configured to connect to the nominated public IP address and, assuming there are no conflicting rules in the rule set, the connection will hit this rule. The connection should then be allowed and the redirect host value in the rule will forward the request to the target host on your internal network.
The service/application used is also important here. If you select "ssh server" this relates to the SSH server process running on the Firewall itself for remote CLI purposes. If your intention is to create a rule to pass SSH traffic through the firewall to another network then you must not use this application but either the normall SSH application definition or a custom definition running on TCP port 22.
Hope that helps.
This rule will only work if the hosts on the external side of your firewall have explicit routes for the internal hosts behind your firewall that point to the external IP of the firewall. The external devices need to send traffic destined to these internal devices to the firewall itself. You need to add a route or routes on those external devices to make this work.
Judging from the screenshots you are running version 7.
sliedl has effectively confirmed my point about the zones. He has confirmed that, based on how the rule has been created, you will need to have explicit routes in place in order for it to work. Either that or, as I maybe didn't explain too well, you will need to tell the users on the external side to connect explicitly to an externally-facing IP address on the Firewall and then redirect it. In order for the rule to work as you have created it, appropriate routing is required and if the internal side is using private addresses I'm not sure the rule will work as you appear to want it to.
If my Firewall had an external IP of 126.96.36.199, and internal address of 192.168.1.1 and the host I want users to connect is 192.168.1.25, this is what I would do.
1. Create an IP address object for 188.8.131.52 (calling it FW_EXTERNAL)
2, Create an IP address object for the SSH server host on 192.168.1.25 (calling it SSH_Server)
3. The create a rule from external burb to external burb, source endpoint = Nessus Host Group, destination endpoint = FW_EXTERNAL, redirect = SSH_Server
By the look of your rule, it appears that you would like to be able to allow the Nessus Host Group to be able to SSH to a number of hosts on the internal side. Using the type of rule I am suggesting you would need to repeat this process for each destination host, or use a netmap address object to create multiple 1-to-1 mappings between IP addresses on the external interface and the SSH server hosts on the internal side, and have sufficient alias IP addresses configured on the Firewall. Also, unless the traffic isn't properly-formatted SSH, I found I was always able to use the system-defined SSH service. Though if you want to use a custom defined service that is up to you.
I made the rules as you suggest but he got the error: Connection closed by remote host. When he tries to ssh directly to the hosts he gets the error connection refused.
BTW I should have mentioned these hosts have a public address not a private one.
I suggest you call into Support and do a remote session with someone to figure this issue out.