Note that the client must request tunneling to the internal
loopback interface, not the external interface of the server host. For
example, if transparent TCP tunneling is used on the client side and the
external interface of the server host has IP address 192.168.92.250,
then the following configuration allows tunnels only to the server host
itself (any port in the loopback interface or the external interface):

By default, SSH Tectia Client binds the listener to the internal
loopback interface on the client side allowing only local connections. If
the allow-relay option is used on the SSH Tectia Client, all client-side
interfaces are used, allowing connections from other hosts unless SSH Tectia
Server denies this with the following configuration:

The configuration allows tunnels originating from the client host only.
However, restrictions based on the source address of local port forwarding
are normally not reliable because the client can forge the source address. A
configuration like this can be used only if the client can be trusted (for
example, if it is administered by yourself).

The following configuration allows tunnels originating from the
example.com domain to the appserver.example.com
ports 2000-9000. The "*" wildcard character matches all
hostnames. As in the previous example, this configuration should be used
only if the client can be trusted:

Deny Rules

The following configuration denies tunnels to the
192.168.23.0/24 domain. If this is the only
tunnel-local rule, tunnels to all other addresses are allowed.
If tunneling is attempted using a FQDN, the server will attempt to match to
the IP addresses using a DNS lookup:

The following configuration denies tunnels to the *.forbidden.example
domain. If this is the only tunnel-local rule, tunnels to all other
addresses are allowed. If tunneling is attempted using an IP address, the
server will attempt to match to the FQDN using a reverse DNS lookup.
However, if this lookup fails, tunneling using IP address is allowed: