This section describes the Network Address List format.
A Network Address List is specified as multi-line text data.Each text line should contain one of the following:
The first IP address can be preceded with the exclamation point (!) symbol. In this case the specified IP address or the address range is excluded from the list composed using the preceding lines.
A comment (separated with the semicolon (;) symbol) the can be placed at the end of a line.
Lines starting with the semicolon symbol, and empty lines are comment lines.
If you use CommuniGate Pro in a corporate environment, most of your users will connect to the Server from the corporate LAN(s).
Use the WebAdmin Interface to specify your LAN Addresses. Open the Network pages in the Settings realm, then open the LAN IPs page.
The LAN IP Addresses table initially contains the addresses the CommuniGate Pro
software retrieved from the Server OS configuration. Correct this list to include all
LAN (local networks) the CommuniGate Pro Server needs to serve.
The Network Address Lists section explains the list format.
Usually, you want all E-mail and Real-Time (VoIP/IM) clients connecting from the LAN addresses to be able to relay E-mails and Signals to any Internet destination. In this case you may want to inlcude the LAN addresses into the Client IP Addresses list.
The list of LAN IP Addresses is used to support Real-Time (voice, video, etc.) communications, so the CommuniGate Pro Server knows which addresses are belong to NAT'ed ("local") addresses, i.e. which addresses cannot be contacted directly from the Internet.
Use the Server LAN IP Address setting to select the Server own IP Address the Server OS uses to communicate with computers on the LAN.
CommuniGate Pro can provide SIP and real-time communications for remote clients located behind NAT devices, implementing the far-end NAT traversal functionality.
To detect clients located behind NATs, the Server needs to know which addresses are used on remote networks behind
Use the WebAdmin Interface to specify the NATed Addresses. Open the Network pages in the Settings realm, then open the NATed IPs page.
If a SIP client sends a request to CommuniGate Pro and the client own network address specified in the request headers is included into the NATed IP Addresses list, while the Server has received this request from a different network address, NOT listed included into the NATed IP Addresses list, the Server decides that this client is behind a NAT.
To allow other users to make incoming calls to a client behind a NAT, CommuniGate Pro keeps the "communication hole" between the client and Server open by periodically sending dummy packets to that client.
If your CommuniGate Pro Server is installed on a LAN behind a NAT/Firewall, the NAT/Firewall device should be configured to relay all connections on its communication (POP, SMTP, SIP, etc.) ports to the CommuniGate Pro Server LAN address. Use this setting to specify the IP address your NAT/Firewall "relays" to CommuniGate Pro.For example, if your CommuniGate Pro Server has the 10.0.1.12 IP address on your LAN, and the NAT/Firewall relays all incoming connections coming to the 188.8.131.52 IP address to the 10.0.1.12 address, specify the 184.108.40.206 IP address in this setting:
CommuniGate Pro supports various real-time communications. Most of those real-time protocols cannot be used via a NAT/Firewall, so CommuniGate Pro can act as "proxy" for those protocols.
When a client on the LAN tries to communicate with a remote system on the Internet (WAN),
CommuniGate Pro creates a Media Proxy - a communication port on its own system.
It forces the client to connect to that Media Proxy instead of the remote system media port.
The CommuniGate Pro Media Proxy communicates with the remote system itself, relaying the data received from the LAN client to the remote system and vice versa.
A Media Proxy is created to serve entries (users) located behind remote NAT devices.
A Media Proxy is created to relay traffic between an IPv4 and IPv6 entries.
Note: the FTP Module uses the ports from the TCP Ports set for Passive Mode transfers.
The CommuniGate Pro Server uses its own high-speed multithreaded Domain Name Resolver to convert domain names into network (IP) addresses. To convert names, the Domain Name Resolver sends requests to the specified Domain Name Servers.
Use the WebAdmin Interface to configure the Resolver settings. Open the Network pages in the Settings realm, and follow the DNS Resolver link.
If the Custom option is selected, the CommuniGate Pro Server will use the DNS servers addresses listed in the text field next to this pop-up menu.
If no DNS server address is specified, the CommuniGate Pro Server uses the 127.0.0.1 address, trying to connect to a DNS server that can be running on the same computer as the CommuniGate Pro Server.
If a response is not received, the Resolver resends the request, and waits twice longer, if it times out again, it can resend the request again and wait three times longer.
If you have several Domain Name Servers specified, each time the resolver needs to repeat a request, it sends it to the next DNS server in the list.
Note: when a request is an RBL request, the Resolver sends the same request not more than twice, and both times it uses the same (Initial) response time-out.
The Domain Name Resolver uses TCP connections if a DNS server sent a UDP response with the "Truncated" flag set. This feature allows the Resolver to retrieve very large records from DNS servers.
Some DNS authorities may choose to "map" all non-existant names within their domains to some special IP address(es).
When a domain name is resolved into IP addresses, the Resolver checks the first address. If this address is listed in the Dummy IP Addresses list, the Resolver returns the "unknown host/domain name" error code.
The Domain Name Resolver caches responses to SRV-type DNS requests.
If the Server runs on a platform with IPv6 support, and it detects any local IPv6 address,
it assumes that the IPv6 networking is enabled.
In this case, the Server creates all network sockets as IPv6 sockets. These sockets communicate with IPv4 systems using the IPv4-mapped IPv6 address method.
Note: The IPv4-mapped IPv6 address method is permanently disabled in OpenBSD system kernels. As a result, IPv6 networking is not supported on this platform.You can explicitly instruct the Server to switch IPv6 networking support on or off by using the --IPv6 Command Line Option:
You may want to deny access to your Server for all incoming TCP connections and UDP packets coming from certain IP Addresses.
Use the WebAdmin Interface to specify the Denied Addresses. Open the Network pages in the Settings realm, then open the Blacklisted IPs page.
The TCP and UDP Listeners consult with this IP Address list before they check their own restrictions settings.
In a Cluster environment, connections and packets from an IP Address are denied if that Address is included into either Server-wide or Cluster-wide Denied IP Addresses list.
You may need to obtain a detailed Log of all communications with certain clients or remote servers.
Use the WebAdmin Interface to specify the Debug Addresses. Open the Network pages in the Settings realm, then open the Debug IPs page.
In a Cluster environment, both the Server-wide or Cluster-wide Debug Addresses lists are checked.