WAN Settings

Configuration of network interfaces which are used for incoming connections.

Other XMPP servers need to connect with the XMPP Proxy for a federation to function. The proxy's server-to-server interfaces can be configured as follows:

• TCP Port
  Enter the TCP port for the XMPP server-to-server interface. The default port, 5269, can be set by clicking the Default button.
• Bind to IP address
  Select an IP address for your system, through which the XMPP server-to-server interface should connect.

Be careful that the Windows® firewall for the computer running XMPP Proxy will not block the port chosen and setup an appropriate rule, if necessary.

Make sure that this interface can be accessed from the public Internet and that your presence domain can be resolved to an IP address through DNS. If a non-standard port has been chosen, a DNS SRV record (_xmpp-server._tcp.domain) can publish this information for_tcp.domain) use by other systems. Ideally, such a DNS SRV record should also exist, if the default port is used. A DNS SRV Record is not absolutely required, since other systems can generally establish a connection to your UCServer using a DNS A Record and the default port 5269.

The options for encrypting the connection, can be set by means of the Advanced button. However, only the connection to the XMPP server for other domains, which also encrypt messages and forward them to remote users, will be encrypted. End-to-end encryption will not be used.

The settings for TLS encryption may either be set globally for all domains or locally for each individual domain. The global settings will apply for all domains, when other settings have not been made. In order of accessibility and trustworthiness, the following categories can be assigned:

• No Encryption
  TLS encryption will not be used for connections with remote domains. This setting should only be selected when the TLS Encryption Optional setting will not work.
  
• TLS Encryption Optional
  An attempt will be made to use TLS encryption with connections to remote domains, if that domain makes such possible and a local certificate is available. If the other domain does not offer TLS support (which is the case with GoogleTalk, for example) then message exchanges will not be encrypted. Otherwise, the attempt will be made to ensure the highest possible level of reliability. This settings will almost always work, but does not guarantee the reliability of the messages.
  
• TLS Encryption Required (Ignore Certificate Errors)
  The attempt will be made to use TLS encryption with connections to remote domains. If a local certificate is not available or the other domain does not support TLS, the connection will fail. If certificate errors occur (for example, because the other domain's certificate has expired or has not been signed by a reliable certification authority), they will be ignored. Connections will offer reliability, however not strong authentication in the other domain.
  
• TLS Encryption with Valid Certificate
  The attempt will be made to use TLS encryption with the connections to remote domains. If a local certificate is not available, the other domain does not support TLS or the other domain's certificate is either invalid or not signed by a reliable certification authority then the connection will fail. This type of encryption is recommeneded, does not however always work (for example, GoogleTalk does not support TLS encryption, many server certificates have expired or they have only been signed by the server itself).
  

TLS encryption is only possible with a valid server certificate. The configuration of a Server Certificate is described inconfiguration of the certificate.