Enhancing SIP reliability in 464XLAT environments 7.6.1

FortiGate can now disable IP address translation within the SIP payload in 464XLAT environments as needed. This ensures SIP packets with IPv4 information reach user equipment without translation, which addresses an issue where the customer-side translator (CLAT) component does not revert the IPv6 address to IPv4 within the SIP header and body, which leads to RTP connection issues in 464XLAT environments. By preventing unnecessary translation, FortiGate ensures seamless communication and robust connectivity to improve the reliability of SIP-based services in complex network scenarios.

FortiGate only uses this feature as needed. A flag is added to each voip_session_stream, and FortiGate uses the flag and other information to identify 464XLAT environments. When a client initiates SIP traffic to a server, such as a REGISTER request to a server, and if the VOIP daemon detects an IPv6 layer address, but the SIP payload header contains an IPv4 address, the payload is identified as for a 464XLAT environment, and FortiGate stops NAT46 on the SIP payload.

Scope and limitations

Only one TCP connection is used between each SIP client and the SIP server, and the TCP connection remains up (in other words, doesn't tear down).

All SIP traffic between each SIP client and the SIP server must use the same TCP connection.

Because of the above requirements, SIP pinhole is not created.

The SIP server must offer its own IP address. The twin case for hnt_464xlat is not supported.

Only SIP/TCP-5060 is supported, and session-helper must be configured:

config system session-helper
    edit 13
        set name sip
        set protocol 6
        set port 5060
    next
end

Example

This example describes the behavior in FortiOS 7.6.0 and earlier followed by a description of the behavior change in FortiOS 7.6.1.

In FortiOS 7.6.0 and earlier when NAT46 IP address translation is enabled within the SIP payload for return traffic, and the address is the server's IPv4 IP in a 464XLAT environment, a connection fails to establish for RTP traffic with the IPv6 destination. The example uses the following topology:

1. The CLAT component run insides the user equipment (UE) and performs a one-to-one (IPv4 to IPv6) stateless translation. The CLAT component translates traffic with an IPv4 destination to IPv6. While the IPv4 address is converted to IPv6 in the IP header, the IP information within the payload, including the SIP header and body, remains unchanged (IPv4).

2. FortiGate as PLAT performs many-to-one (IPv6 to IPv4) stateful translation to translate the IP address within the IP header from IPv6 to IPv4. Furthermore, SIP-ALG modifies the IP address within the payload in the SIP header and body by substituting the IPv4 address with a publicly NATed IP address.

3. When traffic is returned from the SIP server to FortiGate, the IPv4 address within the IP header is translated back to IPv6. Concurrently, the IP address contained within the SIP header and body is also translated back to IPv6 by FortiGate.

4. The packet reaches UE, and the CLAT component translates the IP address of the IP header from IPv6 to IPv4. The CLAT component does not function as an ALG and does not modify the IP address within the SIP header and body.

5. The UE receives the packet but cannot establish RTP connection with the IPv6 destination.

Step 3 changes in FortiOS 7.6.1. For traffic returning from SIP server, FortiGate stops NAT46 on the SIP payload and only translates the IPv4 addresses in the IP header into an IPv6 address. Thus, the IP address contained within the SIP header and body remains IPv4, which the user equipment can recognize, and RTP connections can be successfully established.