No SSH identification string on FG40F v7.2.4

[chets]

I get a super weird issue with a Fortigate 40F ( version 7.2.4 ).

Infrastructure:

• 1 FG40F
• 1 local ssh server on Windows 10

Goal:

SSH server should be accessed on the Internet ( obviously with some protections )

Issue:

When I do a connection via a telnet command from LAN ( with local ip address ) :

$ telnet X.X.X.X 11022
Trying X.X.X.X...
Connected to X.X.X.X.
Escape character is '^]'.                     

SSH-2.0-OpenSSH_for_Windows_8.1      <---- I get a ssh identification string

BUT when I do a connection via a telnet command from Internet ( with a public ip address ) :

$ telnet X.X.X.X 11022
Trying X.X.X.X...
Connected to X.X.X.X.
Escape character is '^]'.                         <----- connection to ssh server from outside but no ssh identification string appears
Connection closed by foreign host.

Additionnal information:

I already have a ftp server ( port 21 ) via a Virtual IP and I have no problem with it but it's not the same with my SSH server.

The FG seems truncated the network flow especially on ssh connection.

Anyone already had this problem ?

[abarushka · Accepted solution]

Hello,

You may consider to sniff the traffic on FortiGate side "diagnose sniffer packet any 'host <server IP address>' 6 0 a", convert to pcap file and check pcap file for anomalies.

[AEK · Accepted solution]

Try this:

- remove any security profile (IPS, AV, SSL inspection, ...) from the policy

- use flow based policy instead of proxy based

[Faiza_Emam_Delhi · Accepted solution]

The behavior you are experiencing with the Fortigate 40F not displaying the SSH identification string when connecting from outside the LAN could be due to the Fortigate blocking or filtering incoming SSH traffic from the Internet.

Here are some potential causes and solutions:

1. Firewall rules: The Fortigate may have firewall rules that are blocking incoming SSH traffic from the Internet. You may need to create a new firewall rule to allow incoming SSH traffic on port 11022 from the Internet. You should also ensure that the rule is placed above any other rules that may be blocking the traffic.

2. NAT settings: The NAT settings on the Fortigate may not be configured correctly. You may need to configure a port forwarding rule on the Fortigate to forward incoming SSH traffic on port 11022 to the internal IP address of the Windows 10 SSH server.

3. Security policies: The security policies on the Fortigate may be configured to block incoming SSH traffic from the Internet. You may need to create a new security policy to allow SSH traffic from the Internet to the LAN.

4. SSH server settings: The SSH server on the Windows 10 machine may be configured to only accept connections from certain IP addresses or subnets. You may need to modify the SSH server settings to allow connections from the Internet.

It may be helpful to review the Fortigate logs to see if any traffic is being blocked or filtered. Additionally, you may want to try connecting to the SSH server from outside the LAN using a different SSH client to see if the issue is specific to the telnet client.

[pavankr5 · Accepted solution]

Hello @chets ,

+ FortiGate firewalls often employ security profiles that can inspect and modify network traffic. Ensure that any security profiles, such as Deep Packet Inspection  or IPS , are not interfering with the SSH traffic. You can temporarily disable these profiles for testing purposes to see if they are causing the issue.

+Make sure that the NAT rules are correctly configured to translate the public IP address to the private IP address of the SSH server.

+ Enable logging on the firewall policies related to SSH traffic. Monitor the logs to see events or errors are being generated when the SSH connection is attempted from the Internet. This can provide insights on why the connection is being terminated.

Thanks,

Pavan

[abarushka · Accepted solution]

Hello,

You may consider to sniff the traffic on FortiGate side "diagnose sniffer packet any 'host <server IP address>' 6 0 a", convert to pcap file and check pcap file for anomalies.

[AEK · Accepted solution]

Try this:

- remove any security profile (IPS, AV, SSL inspection, ...) from the policy

- use flow based policy instead of proxy based

[Faiza_Emam_Delhi · Accepted solution]

The behavior you are experiencing with the Fortigate 40F not displaying the SSH identification string when connecting from outside the LAN could be due to the Fortigate blocking or filtering incoming SSH traffic from the Internet.

Here are some potential causes and solutions:

1. Firewall rules: The Fortigate may have firewall rules that are blocking incoming SSH traffic from the Internet. You may need to create a new firewall rule to allow incoming SSH traffic on port 11022 from the Internet. You should also ensure that the rule is placed above any other rules that may be blocking the traffic.

2. NAT settings: The NAT settings on the Fortigate may not be configured correctly. You may need to configure a port forwarding rule on the Fortigate to forward incoming SSH traffic on port 11022 to the internal IP address of the Windows 10 SSH server.

3. Security policies: The security policies on the Fortigate may be configured to block incoming SSH traffic from the Internet. You may need to create a new security policy to allow SSH traffic from the Internet to the LAN.

4. SSH server settings: The SSH server on the Windows 10 machine may be configured to only accept connections from certain IP addresses or subnets. You may need to modify the SSH server settings to allow connections from the Internet.

It may be helpful to review the Fortigate logs to see if any traffic is being blocked or filtered. Additionally, you may want to try connecting to the SSH server from outside the LAN using a different SSH client to see if the issue is specific to the telnet client.

[pavankr5 · Accepted solution]

Hello @chets ,

+ FortiGate firewalls often employ security profiles that can inspect and modify network traffic. Ensure that any security profiles, such as Deep Packet Inspection  or IPS , are not interfering with the SSH traffic. You can temporarily disable these profiles for testing purposes to see if they are causing the issue.

+Make sure that the NAT rules are correctly configured to translate the public IP address to the private IP address of the SSH server.

+ Enable logging on the firewall policies related to SSH traffic. Monitor the logs to see events or errors are being generated when the SSH connection is attempted from the Internet. This can provide insights on why the connection is being terminated.

Thanks,

Pavan

[chets · Accepted solution]

Hi @All,

This problem has been resolved. My ISP actually has a deep inspection system on WAN link ( for QoS ) and after multiple troubleshootings, I figured out that lack of the "famous string" ( ssh identification ) was because it's removed by the ISP.

I close the issue.

Best regards.