SIP Trunk behind FortiGate – 3CX sending local IP instead of NATed WAN address

[YfNy]

Hi everyone, I’m setting up a SIP Trunk between my 3CX server (on a LAN) and my provider’s MSC, and I’m facing an issue where the 3CX sends its local IP instead of the public (NATed) WAN IP.

The setup is as follows: 3CX (192.168.x.x) → FortiGate LAN (192.168.x.1) → FortiGate WAN (10.x.x.194) → POP ISP (10.x.x.193) → MSC ISP (172.x.x.5). The FortiGate performs outbound NAT, SIP ALG is disabled, and UDP 5060 plus RTP 9000–10999 are open and forwarded to 3CX.

However, during outbound calls, 3CX logs the following message:
Call from "numext"<sip:numext@IP_ISP;transport=udp;user=phone>;tag=xyz to "numcalled"<sip:numcalled@IP_WAN_FORTIGATE;transport=udp;user=phone> has been dropped as it was not acknowledged in time. Please verify configuration and ensure there are no connectivity issues.

Packet capture on the FortiGate shows that traffic to/from the ISP (port 5060) passes correctly, but SIP packets remain fragmented, and the Contact: / Via: headers still contain the private 192.168.x.x address, causing the provider to respond to a non-routable IP (leading to dropped calls and no audio). NAT rules preserve the source port, and RTP/ICMP flows are fine.

I’d like to know if anyone has advice or experience on this: can FortiGate rewrite SIP headers (Contact/Via) with the public NAT IP without enabling SIP ALG, or should 3CX handle the address substitution itself?

Any tips or best practices for SIP trunking behind FortiGate would be greatly appreciated.

[funkylicious]

hi,

as far as i know, its the local PBX the one that should handle/configure this when it sends traffic.

https://www.3cx.com/docs/firewall-checker/