Oracle Communications Diameter Signaling Router (DSR)
 

PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec DSR
 

In this Document

Goal

Solution

References

Created from <SR 3-12714593141>

Applies to:

Goal

The goal of this document is to identify the primary settings in DSR that will aid in successfully establishing Diameter connections to a peer residing behind a Network Address Translation (NAT) firewall or other NAT device.

An ancillary goal of this document is to provide WARNING that interfacing to any peer through a remote NAT device is highly dependent on the capability of the NAT device itself, as well as the connection strategy in use. Oracle DSR does not directly support connections from a NAT'd environment, although depending on configuration and content of received packets/messages such connections may be successful.

Solution

There are two primary reasons that connections to remote peers residing behind NAT equipment will fail.

1. In the Capabilities Exchange Request (CER) and Capabilities Exchange Answer (CEA) messages--collectively referred to as "CEx"--the Host-IP-Address AVP 257 (Attribute Value Pair) will contain the original (i.e. untranslated) IP address(es) of the remote peer. Upon receipt of the CEx message, validation of this AVP will fail because the address(es) are unknown to the DSR's Diameter configuration and the connection will be rejected.
   For DSR to successfully process a CER or CEA message in this scenario, the CEx Host IP Validation must be disabled. This is possible in DSR 6.0 and later releases only.
   To disable CEx Host IP Address validation, the Connection Configuration Set associated with the Connection should have the Diameter Option for 'CEX Host IP Validation' set to 'NO'.
    In some cases, it is also prudent to ensure Peer Node Identification is not conducted.
   To disable Peer Node Identification, edit the Connection and set its Peer Node Identification parameter to 'None'.
2. If Stream Control Transmission Protocol (SCTP) is used for transport, the INIT and INIT_ACK chunks from the SCTP handshake will contain original (i.e. untranslated) IP address(es) of the remote peer. NAT will have translated the IP header addresses, but any use/processing of untranslated IP or addresses not present in the handshake may cause the connection to ABORT.
   DSR will likely successfully process SCTP handshake and CEx exchanges on a uni-homed SCTP connection if the above configuration changes are in place because IP addresses in the IP header are known and pass validation at the kernel level. However for Multi-Homed (MH) SCTP connections, if the NAT device does not alter the addresses contained in the INIT or INIT_ACK chunks, messages received utilizing the secondary path will not be recognized by the SCTP stack or DSR (since secondary address was never translated and presented in the handshake) and subsequently the entire association may be torn down, even if the primary path has established. Per the Internet Engineering Task Force (IETF) Request For Comments (RFC) 4960 standard, the INIT (section 3.3.2) and INIT_ACK (section 3.3.3) chunks must contain the addresses to be used as destinations for the receiver of the chunk.

Attempted use of SCTP Multi-Homed connections traversing NAT devices typically is not successful for the above reason. 

This solution has no attachment