Solved Yet another one way audio post, outbound SIP trunk calls, called party can not hear

[Bill Schalck]

I've been reading various posts about this all morning and can not find anything that could be causing this. I've looked at all the common "culprits" on dozens of posts.

I can make extension to extension calls with no issues with clients that are on and off our internal network.
I can receive external calls from our SIP trunk with no issues.
External calls to our SIP trunk have one-way audio, the called party can not her me but I can hear them.

Here's some information...
On premise 3CX version 15.5.15502.6

One SIP trunk with SIP.US
PBX Delivers Audio is checked on the trunk

Firewall tests all pass
Firewall is Fortigate FG100D v6.0.3 build0200 (GA)
SIP ALG is disabled per this document:
https://kb.fortinet.com/kb/documentLink.do?externalID=FD36405

Ports opened per:
https://www.3cx.com/docs/ports/

Did a packet capture on the DMZ from the firewall (before NAT), have 2500+ packets and I don't know where to start looking at them. Don't really want to post here as capture contains sensitive information.
Thinking a capture on the WAN port might also be helpfull to see what NAT is doing but don't know what kind of filter to apply to that capture. Without a filter there would be 10,000 packets in a few seconds.

One to one NAT between our external IP and the internal IP
The one-to-one nat for the PBX is on a different IP address than our main office NAT. We have a /29 address range with Comcast. The WAN interface is the first useable address in the /29 (.233) range, the 3CX net is the second (.234) and the default gateway is the last (.238)
Firewall is setup with a virtual IP and inbound rule for the one-to-one NAT inbound and a second firewall rule for the one-to-one NAT outbound. This is per this document:
https://forum.fortinet.com/tm.aspx?m=136309

Tried rebooting 3CX server, did not make any difference.

I see a lot of blocked traffic to the 3CX at the firewall, but it's all on various random ports that appear to be hackers probing:
RDP Deny: policy violation Implicit Deny
TCP/27019 Deny: policy violation Implicit Deny
TELNET Deny: policy violation Implicit Deny
TCP/4106 Deny: policy violation Implicit Deny
TCP/47675 Deny: policy violation Implicit Deny
TCP/31415 Deny: policy violation Implicit Deny
TCP/32169 Deny: policy violation Implicit Deny
TCP/53055 Deny: policy violation Implicit Deny
TCP/9265 Deny: policy violation Implicit Deny
TCP/5008 Deny: policy violation Implicit Deny
TCP/3007 Deny: policy violation Implicit Deny
TCP/4340 Deny: policy violation Implicit Deny
TCP/50138 Deny: policy violation Implicit Deny
SSH Deny: policy violation Implicit Deny
etc... etc... etc...

Any suggestions on what to look at next would be appreciated.

 

[nobody]

Is it possible that you somehow missed to create a rule to send outgoing traffic of the pbx via the correct IP Address? My guess is that rtp traffic is sent using the first (default?)ip, and not the 234/second ip. Therefore the firewall/nat system on the called party side might discard this data since it originates from the wrong ip address.

 

[Bill Schalck]

@nobody I thought of that, however
1) I would think the firewall test would catch that
2) Inbound calls are always fine
3) The document that I referenced for the firewall https://forum.fortinet.com/tm.aspx?m=136309 discusses TWO steps that must be complete for the NAT rule to work, one for inbound and one for outbound. I completed both.
So I don't think that is the problem, and I'm not sure how I could prove it. Although you did give me a good iead to try. I may try to do a packet capture on the WAN interface with the NATed address of the 3CX and see what that looks like.

 

[Bill Schalck]

Well, thank you @nobody. I discovered that the posting that I was relying upon for my one-to-one static NAT configuration was incorrect in one direction. Found another one that explains it properly in case anyone in the future has a similar problem.
https://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD31893

Discovered this when I did a network capture on the WAN with the public NAT address. Calls that worked had about an equal number of packets on the WAN and LAN. Calls that had one way audio had significantly more packets on the LAN than on the WAN. I guess packet captures do actually solve all the worlds problems

 

[Bill Schalck]

Silly followup "how to" forum question. I'd like to mark my post solved. Can't figure out how to do this.

 

[YiannisH_3CX]

Glad to see the issue has been resolved and thank you for updating the thread with your solution.