The following configuration allows tunnels to imap.example.com ports 143 and 993. If this is the only tunnel-local rule, tunnels to all other addresses are denied:

<rule>
  <tunnel-local action="allow">
    <dst fqdn="imap.example.com" port="143" />
    <dst fqdn="imap.example.com" port="993" />
  </tunnel-local>
...
</rule>

Opening the tunnel with a matching IP address should also work. Opening any other tunnel with IP address is denied.

The following configuration allows tunnels to 192.0.2.99 port 143. If this is the only tunnel-local rule, tunnels to all other addresses are denied:

<rule>
  <tunnel-local action="allow">
    <dst address="192.0.2.99" port="143" />
  </tunnel-local>
...
</rule>

Opening the tunnel with a matching FQDN should also work. Opening any other tunnel with FQDN is denied.

The following configuration allows tunnels only to the server host itself (any port in the loopback interface):

<rule>
  <tunnel-local action="allow">
    <dst fqdn="localhost" />
  </tunnel-local>
...
</rule>

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):

<rule>
  <tunnel-local action="allow">
    <dst fqdn="localhost" />
    <dst address="192.168.92.250" />
  </tunnel-local>
...
</rule>

By default, 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 Tectia Client, all client-side interfaces are used, allowing connections from other hosts unless Tectia Server denies this with the following configuration:

<rule>
  <tunnel-local action="allow">
    <src address="127.0.0.1" />
  </tunnel-local>
...
</rule>

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:

<rule>
  <tunnel-local action="allow">
    <src fqdn="*.example.com" />
    <dst fqdn="appserver.example.com" port="2000-9000" />
  </tunnel-local>
...
</rule>

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:

<rule>
  <tunnel-local action="deny">
    <dst address="192.168.23.0/24" />
  </tunnel-local>
...
</rule>

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:

<rule>
  <tunnel-local action="deny">
    <dst fqdn="*.forbidden.example" />
  </tunnel-local>
...
</rule>

To explicitly deny this, use a configuration similar to the following one:

<rule>
  <tunnel-local action="deny">
    <dst fqdn="*.forbidden.example" />
    <dst address="0.0.0.0/32" />
  </tunnel-local>
...
</rule>

This denies all local tunneling attempts using IP addresses.

Note that the tunneling rules are not intended to replace other access control mechanisms. If strict access control is required, it should be implemented at the application servers.