Listeners

TCP and UDP services use Listeners to accept incoming connections and packets. Each Listener can use one or several listener sockets.

A listener socket accepts incoming TCP connections or receives UDP packets on the port number you specify. You should also specify if the socket should accept connections or receive packets on all IP addresses your server computer has, or only on a selected address.

For example, you may want to create a socket that accepts all connections on one local IP address, while the other socket is used to accept connections on the other local IP address - and only from the specified networks.

Because of the nature of TCP sockets, you cannot have two listener sockets that use the same port number and the same local IP address: if you create a listener socket on the TCP port N that works with ALL local IP addresses, you cannot create a different socket on the same port N. If you create a listener socket on the TCP port N and a specific local address xx.xx.xx.xx, then you can create a different listener socket on the same TCP port N and a different local address yy.yy.yy.yy.

If your CommuniGate Pro Server coexists with some other server software, such as a third-party Web server, you may want to configure that Web server to use one local IP address, while your CommuniGate Pro server would provide its HTTP services on a different local IP address - but on the same port number. If that port number is 80, and the domain name www.company.com resolves into the first IP address, while mail.company.com resolves into the second IP address, then typing http://www.company.com in a client browser will bring up the third-party Web Server home page, while typing http://mail.company.com will bring up the CommuniGate Pro Login page - with both servers running on the same server computer.

To create a new listener socket, change the value in the last table element from 0 to the desired port number and click the Update button.

To remove a listener socket, change its port number to 0 and click the Update button.

Even if your server has only one IP address, you may want to create two listener sockets for most of your TCP services: one for regular, clear text connections and one (on a different port number) for secure connections (see below).

You may want a listener socket to accept connections or to receive packets only from certain remote network (IP) addresses.

If the remote IP address of an incoming connection or a received packet is included into the Denied IP Addresses list, the connection is rejected and the packet is dropped.

If you set the Restriction setting to Grant, and list the IP addresses in the text field, the socket will accept connections or packets from the specified addresses only.

If you set the Restriction setting to Deny, and list the IP addresses in the text field, the socket will deny access to all clients trying to connect from the specified (blacklisted) addresses.

The IP addresses are specified in a multi-line format. See the Network section for more details.

There is a difference between the Access Restrictions on the listener socket level, and the restrictions set in the SMTP module. When a remote site connects to your server SMTP port and the site IP address is not accepted by the listener socket, the connection is closed immediately. As a result, the remote site will try all other IP addresses of your server, and then it will try to relay mail via your back-up server.

On the other hand, if the remote site address is included into the Server Protection Black-List, SMTP sessions are not closed immediately. Instead, the SMTP session starts and the remote (blacklisted) server is allowed to send the addresses of message recipients. But the SMTP module rejects each address with a "fatal error" code, thus stopping the blacklisted host from trying to relay those messages via your back-up servers.

There is a difference between the Access Restrictions on the listener socket level, and the restrictions set by the Grant Access to the Clients Only option. When a remote site connects to your Server POP, IMAP, WebUser, or other access-type port and the site IP address is not accepted by the listener socket, the connection is closed immediately. As a result, the remote site may try all other IP addresses of your server (and you may have different access restrictions on listener sockets serving those addresses).

On the other hand, if the remote site address is not included into the Server Client IP Addresses list, sessions are not closed immediately. Instead, an access-type session starts, and, if the Grant Access to Clients Only option is enabled, an error message is sent to the remote site before the module closes the connection.

The Init SSL/TLS option is available for TCP Listeners only.

Set the Init SSL/TLS listener socket option to On to tell the Listener component to initiate SSL/TLS negotiations as soon as a connection from a remote site is accepted. Only when a secure connection is established, the Listener allows the communication module to initiate its own protocol (IMAP, HTTP, etc.) - on top of the secure SSL/TLS protocol.

Note: Please read the Security section and configure your Domain TLS certificates before you set this option to On.

Note: When a Listener accepts a connection on a Secure Socket, it tries to detect the CommuniGate Pro Domain the client has connected to. At this time no information has yet been transferred from the client to the server, so the local server IP address the client has connected to is the only data CommuniGate Pro can use to detect the target Domain.
If you want a Domain to have its own Security Certificate and to use it for Secure Socket connections, that Domain must have an IP address assigned to it.

When the Domain is selected, the Listener retrieves the Domain Certificate and initiates a secure (SSL/TLS) session. If the selected Domain does not have a Certificate, the connection is dropped and an error message is placed into the CommuniGate Pro Log.

Note: The current versions of the Internet protocols support the STARTTLS/STLS or equivalent commands. These commands are used to provide secure communications without creating a special Secure Socket on an additional port. Instead, a regular port is used, and a regular, non-secure connection is established, and then the client sends the STARTTLS or an equivalent command, and the client and server initiate the SSL/TLS session. If the software you use employs the STARTTLS command (as most SMTP software packages do these days), then you do not need to create any special Secure Socket for secure (SSL/TLS) communications.

Set the Init SSL/TLS listener socket option to Ext to tell the Listener component that all connections coming to this socket are SSL/TLS secured, but that there is an external device implementing all SSL/TLS encryption/decryption operations.
Connections coming to these ports are clear-text connections, but higher-level CommuniGate Pro components and protocols process these connections as if they come encrypted: clear-text Login operations are considered secure, STARTTLS operations are prohibited, etc.

The connection-limiting options are available for TCP Listeners only.

To prevent various Denial of Service (DoS) attacks you may want to limit the number of connections a Listener can accept (on all sockets) from the same IP address:

The Non-Client setting applies only to the TCP connections from Network IP Addresses not included into the Client IP Addresses list. This setting value should be equal or smaller than the main Limit Connections setting value.

When you set these settings, you should remember that:

• IMAP clients usually open several connections to the server. If you set this setting for the IMAP listener to less than 5, you can cause problems for your users.
• Web browsers can open several simultaneous connections to retrieve embedded graphic files and other HTML page elements.
• Many Web clients can connect to your server via the same proxy, and they all appear as connecting to your server from the same IP address.

Note: to avoid problems with inter-server communication, this setting has no effect on connections that come from other Servers in the same CommuniGate Pro Cluster.

To prevent various Denial of Service (DoS) attacks you may want to set aside a certain number of available TCP connections for those who connect to your Server from Client IP Addresses.

If the difference between the maximum number of allowed connections and the number of active connections is equal to or smaller than the specified Reserve value, connections from non-Client IP Addresses are rejected.