The following configuration allows opening a listener to port 8765 on the interface 10.1.60.16 on the server and allows connections to it from all addresses. If this is the only tunnel-remote rule, attempts to open remote port forwarding to other interfaces or other ports will be denied:

<rule>
  <tunnel-remote action="allow">
    <listen address="10.1.60.16" port="8765" />
  </tunnel-remote>
...
</rule>

The following configuration allows opening any port on any interface on the server but allows connections only from the listed addresses:

<rule>
  <tunnel-remote action="allow">
    <src fqdn="alpha.example.com" />
    <src fqdn="beta.example.com" />
  </tunnel-remote>
...
</rule>

By default, only users with administrative privileges can create listeners to privileged ports (below 1024). To allow any user to create listeners to privileged ports, enable the disable-privilege-check attribute, similar to the following:

<rule>
  <tunnel-remote disable-privilege-check="yes" action="allow">
  ...
  </tunnel-remote>
</rule>

The following configuration denies opening ports 1-9000 on the server. If this is the only tunnel-remote rule, it allows opening all other ports:

<rule>
  <tunnel-remote action="deny">
    <listen port="1-9000" />
  </tunnel-remote>
...
</rule>

The following configuration denies connections to ports 1-9000 from the listed addresses. However, listeners can be opened to these ports (with ports 1-1023 restricted to admin users only) and all other addresses can connect to them. If this is the only tunnel-remote rule, it allows opening all other ports and allows connections to them from all other addresses:

<rule>
  <tunnel-remote action="deny">
    <listen port="1-9000" />
    <src fqdn="gamma.example.com" />
    <src fqdn="delta.example.com" />
  </tunnel-remote>
...
</rule>

A rule like the above probably does not have any practical use. Nevertheless, it is shown here as an example of the rule logic.