|
Example Scenario:
Consider a VoIP network where internal devices reside in the 192.168.1.0/24 subnet. The FortiGate is configured to translate private IP addresses to a public IP using NAT. Below is how FortiGate processes the traffic:
First Session (Outbound):
The outbound VoIP traffic originates from within the 192.168.1.0/24 subnet. FortiGate translates the source IP to the IP specified in the IP Pool (for example, 203.0.0.1) before reaching the Internet. Outbound session entry:
- Source IP: 203.0.0.1 (NATed IP).
- Destination IP: 198.51.100.42 (VoIP server).
- Port: 5060 (SIP traffic).
Second Session (Inbound/Return):
When the destination (198.51.100.42) replies to the VoIP traffic, it targets the NATed IP (203.0.0.1). FortiGate creates a separate session to manage the incoming return traffic:
- Source IP: 198.51.100.42 (VoIP server).
- Destination IP: 203.0.0.1 (NATed IP).
- Port: Random (dynamically assigned source port from the originating VoIP server).
This separate inbound session is essential for FortiGate to associate the incoming traffic with the correct internal source IP within the 192.168.1.0/24 subnet.
Why this behavior occurs:
FortiGate maintains separate session states for outbound and inbound (return) traffic when using NAT. This is necessary for the following reasons:
- Session Tracking: FortiGate ensures each packet is correctly translated back to the original internal IP (192.168.1.0/24) for inbound traffic.
- Return Traffic Management: Without the second session, FortiGate would be unable to associate return packets with the correct internal VoIP client, leading to broken connections.
Synchronization of RTP and SIP Sessions:
The RTP session must be fully active, with traffic flowing both ways on the same unit as the SIP session, before synchronization can occur. The SIP control session cannot exist on one unit while the RTP session runs on another.
Both must start on the same unit for synchronization to function correctly.
Confirm the creation of both sessions (outbound and inbound) using the following session list command:
This will show a real-time session view, which will confirm proper NAT behavior for VoIP traffic.
For more details on session synchronization, refer to Fortinet’s official documentation: Technical Tip: FGSP Configuration Guide for Session Sync and Config Sync.
The session-pickup-expectation and session-pickup-nat options apply specifically to FGSP, ensuring seamless session synchronization across FortiGates.
FortiGate flow and session tracking limitations under IPsec with NAT-T:
FortiOS session tracking is optimized for clear-text traffic. Once traffic is encrypted and encapsulated, tracking mechanisms may not correctly link SIP control and RTP media sessions.
SIP Over IPsec with NAT Traversal as Best Practices.
When SIP traffic traverses an IPsec VPN, especially with the NAT Traversal enabled, additional encapsulation of UDP port 4500 may interfere with SIP and RTP session tracking.
- Disable SIP inspection.
- Explicitly allow SIP and RTP services over VPN tunnel (udp-portrange 10000-20000).
- Create bidirectional IPsec policies, including RTP.
Note: Verify NAT IP and session entries are symmetric, compare inbound vs outbound NAT in the session table.
Related Behavior with SIP helper and NAT.
FortiGate uses a built-in SIP session helper to rewrite SIP headers during NAT translation.
In complex deployments, especially those involving PBXs, SBCs, or IPsec tunnels, this behavior can sometimes result in one-way audio or call signaling issues.
In such a scenario, refer to the following article for detailed troubleshooting guidance:
Troubleshooting Tip: One way Audio issue in VOIP (with SIP ALG)
To verify the session helper in the configuration:
config system session-helper
show full | grep edit 13
show full | grep port 5060
show full | grep sip
Related articles:
Technical Tip: VoIP and SIP configuration and troubleshooting resource lists
Technical Tip: Disabling VoIP Inspection
|
