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/IP 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 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 port N and a specific local address xx.yy.zz.tt, then you can create a different listener socket on the same port N and a different local address xx.yy.zz.tt.
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 TCP 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 services: one for regular, clear text connections and one (on a different port number) for secure connections (see below).
Note: Please read the Security section and configure your domain certificates before you enable any Secure Socket. When a Listner accepts a connection on a Secure Socket, it tries to detect to which CommuniGate Pro Domain the client has connected. At the time of connection no information has yet been transferred from the client to the server, so the local IP address is the only thing CommuniGate Pro can use to detect a domain. If you want some domain to have its own Security Certificate used for Secure Socket connections, that domain MUST have an IP address assigned to it.
When the domain is selected, the Listener retrieves its Key and Certificate to initiate a secure (TLS) session. If the selected Domain does not have a Key or a Certificate, the connection is dropped and an error message is placed into the CommuniGate Pro Log.
If you set the Restriction setting to Grant, and list the IP addresses in the text field, the socket will accept connections 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 should be specified in the multi-line format: each line should contain either one IP address or a pair of addresses (separated with the minus (-) sign) that specify an address range. A line can contain a comment text after a comment separator. The semicolon (;) sign, the percent (%) sign, or the minus (-) sign can be used as comment separators.
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.