Tag Archives: VPN Connectivity

The resulting benefits of a VPN can, depending on the VPN protocol used, be supplemented by encryption that enables tap-proof and manipulation-proof communication between the VPN partners.

How to SSH Tunnel Reverse Port forwarding

How to build VPN Tunnel using SSH Port Forwarding

Linux has build in SSH from the start, Apple has also integrated Secure Shell into macOS, Microsoft provide OpenSSH on Windows 10 from 1803 and Server 2019 as an optional feature. There are also SSH Tunnels and SSH port forwarding known from tools like PuTTY and KiTTY. So why use SSH only as Terminal (TTY), as VPN Tunnel there are useful opportunities too, for example, VPN is not able because firewall is not capable, or additional software cannot be installed in corporate networks, because the required authorization is not given. An SSH Reverse Tunnel is always useful for devices they are not reachable behind the firewall.

How to use SSH as a VPN Tunnel with port forwarding use OpenSSH on Linux, macOS and Windows

SSH Tunnel to Remote Host B

Here as an example, a tunnel is built from host A to host B, host B is a web server from which the intranet page is to be opened on Host A. The only requirement is that there is a NAT mapping via port 22 to host B on the firewall (NAT router) and that the SSH service is present on each host.

SSH Tunnel Reverse port forwarding to Remote Host B
Illustration: ssh tunnel host A to host B

Run the command in the Linux terminal on Host A as follows:

$ ssh -NT -L 80: cherry@ -p 45680

On Host A, the web page can now be opened http://localhost. The SSH tunnel enable port forwarding for TCP port 80 on Host B from to the localhost on Host A, the external port is 45680. Just we log on to Host B with user cherry.

The parameters:
-L = Local port
-N = do not run a remote command
-p = External SSH port (NAT port on firewall)
-T = do not open a terminal

On Host B the SSH daemon must be configured and activated, in the configuration file /etc/ssh/sshd_config the following settings are required, for many Linux distributions this is default.

# Force SSH Protocol 2
Protocol 2
#Turn on Privileged Separation for security
UsePrivilegeSeparation yes
#Deny root login
PermitRootLogin no
#Do not allow empty passwords
PermitEmptyPasswords no
# installations will only check .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys
# Forward my X Sessions
X11Forwarding yes
X11DisplayOffset 10
# I hate Motd displays
PrintMotd no
# It's alliivee
TCPKeepAlive yes
#AllowTcpForwarding yes

  The lines commented out with hash mean they are default values, e.g. #AllowTcpForwarding is by default yes.

Hint! OpenSSH also available on Synology NAS, FreeNAS, FreePBX Distro, OpenWrt, Raspberry Pi (Raspbian) and now on Windows Servers.

SSH Tunnel to Remote Host C

In this example, an SSH Tunnel is built from Host A to Host C, Host C is an RDS terminal server, Host B serves as a port forwarder.

example, SSH Tunnel Reverse port forwarding built from host A to host C
Illustration: ssh tunnel host A to host C

Run the command in the Linux terminal on Host A as follows:

$ ssh -NT -L 3389: cherry@ -p 43389

The Remote Desktop session to Host C is built via localhost on Host A, by pressing the Win + R key opens Run, to confirm the input mstsc /v:localhost with OK.

Run mstsc

  This example uses the tcp port 3389 for RDP as both internal and external port. All unprivileged ports (-L) higher than 1024 can be used, if a port other than 3389 is used, then the port must be passed to RDP for execution, e.g. mstsc /v:localhost:44389

For Host B, the kernel must be enabled for IP forwarding, which is command for this in the shell as root:

$ net.ipv4.ip_forward = 1

Alternatively, echo in the Shell Console does the same thing:

$ echo 1 > /proc/sys/net/ipv4/ip_forward

Check the current IPv4 forward status as follows:

$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

The value 1 for activation, 0 applies deactivation. The change is not boot persistent, so that after the next start the IP forwarding is active again, edit using nano or sudo vi /etc/sysctl.conf

Controls IP packet forwarding
net.ipv4.ip_forward = 1

It is recommended to use an SSH key for authentication, a key pair can be created as follows:

$ ssh-keygen -f ~/.ssh/key_rsa -t rsa -b 4096

The public key ~/.ssh/key_rsa.pub is stored in the user’s home path, here in this example on Host B under the path in the file .ssh/authorized_keys.

  Authentication using SSH keys is not only more secure, there are other advantages, for example, the user is not asked to enter a password, also the SSH tunnel and other commands can be executed from a script.

SSH Tunnel on macOS

For Apple macOS, SSH is available after activation, open Terminal and run this command as follows:

$ sudo systemsetup -setremotelogin on

After that, the SSH Tunnel can be set up under macOS.

$ ssh -i ssh/key_rsa -NT -R 3389: cherry@ -p 43389

Remote Desktop for Mac Gateway on localhost is now registered and the RDP session can be opened, in this way terminal servers are protected and can only be reached via SSH.

macOS also offers the possibility for automation and uses launchd and the launch system services, the following script is created at: @/Library/LaunchDaemons/server.hostc.client.cherry.home.plist with the following content:

<plist version="1.0">
	  <string>-o ServerAliveInterval=60</string>
	  <string>-o ExitOnForwardFailure=yes</string>
	  <string>-R 3389:</string>
          <string>-p 43389</string>

OpenSSH Server Installation from PowerShell

For Windows Server 2019, the OpenSSH server can also be deployed with elevated rights from the PowerShell opened as administrator.

PS C:\> Get-WindowsCapability -Online | ? name -like *OpenSSH.Server* | Add-WindowsCapability -Online
  Windows 10 OpenSSH client can be found in the settings, under Apps & Features – Optional Features – OpenSSH Client.

FortiGate subnet overlapping remapping

FortiGate in a site-to-site VPN configuration, the private IPv4 Subnet addresses at each scheduled end can often be the same. The problem can be solved by remapping the private IPv4 addresses using virtual IP addresses (VIP).

VIPs allow computers in its overlapping private subnets to be assigned a different range of IP addresses, and the subnets can be used transparently. The FortiGate appliance converts the VIP addresses to the original addresses. This means that if PC1 starts a session with PC2 at, FortiGate_2 the session to PC2, which actually has the IP address

Figure shows – Finance Network VIP is and the HR network has

example overlapping subnets
Overlapping subnets Example

Configuration of a route-based VPN solution:

Create an IPsec Phase 1 and Phase 2, as you would normally do for a route-based VPN. This example refers to the resulting IPsec interface as IPsec_FGT1_2_FGT2.

Configuring Virtual IP (VIP) Mapping, under Policy & Objects > Virtual IPs > Create New

FortiGate New Virtual IP
New Virtual IP

Create IP Pool for Subnet Remmaping under Objects – IP Pools.

FortiGate new dynamic ip pool
New IP Pool

Configure an outbound policy on both FortiGate, under Policy & Objects > IPv4 Policy > Create New, Leave the Policy Type on Firewall and the Policy Subtype as the address:

FortiGate Policy outbound
Policy outbound

To configure the inbound policy:

FortiGate new policy
Policy inbound

To configure the Static Route:

new static route
Static Route

Repeat this process on both FortiGate, FGT1 and FGT2, taking into account the corresponding subnets, and