[3CX Remote office] No inbound audio from external source

[Don_Zalmrol]

Hi all,

So I have a functioning set up with my 3CX in my other office.
Now I have a secondary office which I wish to incorporate with my 3CX.

Both offices have a fixed IP address, FQDN, etc all up and running.
For easy working I have set up the Border Session Controller. Which is also working.

On my main office where 3CX is installed, I can see my remote office extension listed through the BSC.
When I call the phone in the remote office, I can hear audio coming from the office phone. But my cell cannot send audio back.

So it's stuck in one-way traffic. The firewall is set up the same way, I even got a Branch Office VPN running between the two sites thanks to my Watchguard firewalls (any-any between the VPN).

It should be working, but nothing is coming back in. My firewall logs don't show any drops or blocks either...
Anybody encountered this before?

Thanks in advance,

Laurens

 

[agesen]

One way Audio sounds like a NAT issue.

Regards Nanna

 

[Don_Zalmrol]

Hi Nanna,

Indeed, but why?
The firewall rule is working.

Site A has full ingoing and outgoing audio.
Site B only has outgoing audio working. Incoming is blocked.

So it must be an issue in the BO VPN that is set up between Site A and Site B.

 

[agesen]

I don't know what firewall you are using, in our case we have extension on a different "leg" that the one 3cx is installed on.

I had to manually add NAT rules to get Audio to work.

In our case the rules looks like this (Checkpoint FW)

Rule 1

Original Package........................................Translated Package
Source (lan a) - Destination (lan b)..................Source (Original) - Destination (Original)

Rule 2

Original Package........................................Translated Package
Source (lan b) - Destination (lan a)..................Source (Original) - Destination (Original)

Nanna

 

[Don_Zalmrol]

Hi Nanna,

I'm using two Watchguard XTM devices.
Perhaps you are right and I need to define a separate NAT rule or perhaps even a static route from site B to site A.

 

[agesen]

I would give it a try

 

[Don_Zalmrol]

Same problem
Can't seems to pinpoint it.

 

[datamerge]

Hi Don

I have followed this thread and it seems along the way you are giving conflicting information. In some cases you say the PBX is on 192.168.98.120, then 192.168.99.120. I know you are not using real IPs, but relative to each other this makes it impossible to decipher your traceroutes and examples.

Firstly, there is no harm in displaying your internal IP addresses as they are and it would a lot more helpful if you do. Nobody can hack your system knowing your internal IPs unless they know your external IP and a lot more information.

Is your PBX in the voice subnet with your phones, or the data subnet?

When you setup the BOVPN on the Watchguard did you create two tunnels? I.E.

Site A:
Adata -> Bdata
Avoice -> Bdata

Site B:
Bdata -> Adata
Bdata -> Avoice

With Watchguard BO VPN, like most VPN implementations on Linux based routers, you must create tunnels between any subnets that will communicate. You cannot do this with any form of routes. You need BOTH tunnels.

If your PBX is indeed in the voice VLAN, I would guess that you have done the tunnels correctly, or your phones could not even register. If the PBX is in the data VLAN, then your phones could register, but (in a normally setup system without modified options such as PBX delivers audio and SBCs, etc) the phones will try to communicate directly with each other, so there needs to be a way for phones to communicate directly with phones. This in itself should cause no way voice, but there may be other issues at play also.

You need to Wireshark this to see what is going wrong. At the moment you are assuming that there is a routing issue. I have setup hundreds of Watchguards with and without BOVPN. If you have the tunnels right and you have as you say anybovpn to anybovpn, any port and it is high enough in the rule list so it always gets hit, you should be fine.

Here are some points to note with Watchguard (similar to many other routers/firewalls).
Watchguard uses a single policy in both directions. Depending on which direction traffic starts, the policy that evaluates to that traffic is the policy that will carry the data in both directions. In your case, the any bovpn to any bovpn is the only policy, but it is an important oft misunderstood point.

As of about a week ago, the IPS signatures in Watchguard will interfere with SIP ACK (block it), so make IPS is not ticked on in your any bovpn policy. It won't affect your current issue, but it will cause other problems, so since we are talking about Watchguard, save yourself some pain.

You can packet capture in the Watchguards from FSM, or the CLI, but I would suggest you first run Wireshark on your computer. If you installed full graphical Debian you can run Wireshark as easily as on a Windows PC. If not you can either use TShark (text version), tcpdump (similar to TShark), or you can install XLaunch (XWindows server) on a Windows PC and run Wireshark on your Linux box through XLaunch to your PC screen. This is how I run Wireshark on client Linux boxes and from my Linux VMs in my own office.

When you run Wireshark, you can then use the amazing VOIP analysis tools to look at the call flow and see what IP addresses and ports are negotiated for the RTP. You can also see if the RTP stream is even leaving site B and whether it has the correct address and port in its destination.

Speculating on what might be happening without a trace is a pointless and frustrating (for you excercise). Until you can see the traffic you can't fix it.

Regards

Mark