Remote Access Design

[Vipmaddog]

Hi All,

Currently, we are using SSH as a remote access gateway and putty as a remote client for the local port forward (SSH tunnel) to the port of RDP to the end user workstation. It can reduce the network risk by the remote client workstation and control the destination.

https://www.cloudqubes.com/hands-on/linux/port-forwarding-with-putty/

May I know that any design by using Fortigate firewall to have similar SSH tunnel?

For VPN connection, the remote client have internal ip address and access rights as same as located at internal network that I don't prefer.

thx

[abarushka]

Hello,

As far as I understand the goal is to send RDP traffic over SSH. And SSH traffic is sent via IPsec/SSL VPN tunnel. Can you please confirm whether it is correct? 

[Vipmaddog]

Hi,

I think you may say it in this way 

Thx..

[Markus_M]

Hi Vipmaddog,

I think that does not work what you are trying to adapt. Simply trying it will show you

open failed: administratively prohibited: open failed

You should not indulge the idea of FortiGate as jumpserver to your whole network but logon to a specific server with specific passwords and control access from FortiGate if possible, use a odd high port as well. FortiGate should not allow login from outside. Also your SSH server inside the network might be more flexible with SSH key authentication vs password authentication.

Best regards,

Markus

[Vipmaddog]

Hi Markus,

Do you mean you suggest keep using SSH server?

Actually, i would like to identify the solution from Fortigate to replace it in order to reduce the server maintenance of ssh.

Thx

[gfleming]

You can just leverage SSL VPN or IPSec VPN which is basically what you are doing today with SSH. All three of these solutions move data in an encrypted tunnel. You've just chosen to use SSH as your security blanket. The FortiGate will not use SSH to encrypt and tunnel traffic but will use TLS (SSL-VPN) or IPSec to do this. It's much more user-friendly as well as users do not have to remember port numbers and such:

https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/729214/vpn

Another option in the Fortigate world would be Zero Trust Network Access: https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/101256/ztna-tcp-forwarding-a...

The FortiGate acts the same way as the SSH server in your scenario.

[Vipmaddog]

Hi Graham, noted with thanks.

[srajeswaran]

Unless you block it using an IPS inspection profile, the SSH tunneling is expected to work. Can you check if there any UTM profiles active on the policy dropping this traffic ?

[Vipmaddog]

Hi Suraj,

I would like to replace the solution of ssh and putty client rather than keep it. 

For VPN client, it will allow the external client as internal workstation that i don't want. 

For Ssh + putty client solution, we can release on port for external connection and we can restrict the port forwards destination at server end. It will be a good solution. However, i don't want to maintain the server by using fortigate.

Thx

[gfleming]

You can be as granular as you are today using your SSH tunnel as you can on the FortiGate leveraging SSL VPN remote access. Yes VPN clients essentially become "internal workstations" but only insofar as how much access you give them in your VPN remote access policies. So if you only want clients to access one server on one port (as you do with SSH port forwarding) you can do that with the SSL VPN. It's probably way easier to manage on the Fortigate than it is on SSH. For both the admin and the users.

As mentioned in my other reply there is also ZTNA which is closer in operation to SSH tunnelling but requires FortiClient EMS licensing which is an additional cost.