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

Discussion in '3CX Phone System - General' started by Don_Zalmrol, Oct 31, 2016.

Thread Status:
Not open for further replies.
  1. Don_Zalmrol

    Joined:
    Apr 25, 2012
    Messages:
    45
    Likes Received:
    0
    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
     
  2. briankayser

    Joined:
    Jul 19, 2016
    Messages:
    49
    Likes Received:
    5
    Do you have "PBX Delivers Audio" set for your extensions? I'm not saying you HAVE to check that, but I am wondering if it works that way or not. It is most likely an IP routing issue. You mentioned the Session Border Controller SBC, and a firewall, but then you also mentioned a VPN. If you have a VPN between the sites you don't really need to use the SBC and the firewall shouldn't even come into play.

    Do you have full VPN route-ability using internal private IPs? Can your extension get to your 3CX server via the VPN?

    Can you better explain your environment?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. Don_Zalmrol

    Joined:
    Apr 25, 2012
    Messages:
    45
    Likes Received:
    0
    Hi Brian,

    I have two offices with both a fixed IP, a VPN runs between them.
    On site A:
    - Data LAN
    - Voice LAN

    On site B:
    - Data LAN only

    My VPN is set up to allow traffic between site A and B without any rules (any in, any out).
    The networks of site A are accessible on site B and vice versa (ping reply, remote PBX access).

    The remote extension on site B can pull the provisioning file from site A's voice LAN without any issues, the BLF on the remote extension also indicates extensions from site A as available or non-available.

    I've tried using SBC as I am running into this issue and read that the SBC could resolve any firewall incompatibility between SIP calls and remote offices.

    PBX delivers audio is enabled, when disable it, the result is the same.
    Outbound audio is working (from extension to e.g. cell phone or other extension)
    Inbound audio is not working (dead silence, no drops or denies on the firewall)

    Thanks,

    Laurens
     
  4. briankayser

    Joined:
    Jul 19, 2016
    Messages:
    49
    Likes Received:
    5
    All I can think of now is possibly a FQDN issue. How does it resolve at Site B? Internal or External IP?

    Say your 3CX is 10.1.1.10 internally and 212.100.100.50 externally.
    Say your FQDN is Bobsbikes.3cx.us and it resolves to 212.100.100.50 externally. Internally you probably want your phones to resolve to 10.1.1.10. Let's say Site A does that because you added Bobsbies.3cx.us to your internal DNS as 10.1.1.10 (for split DNS.)

    But at Site B, is Bobsbikes.3cx.us resolving to 212.100.100.50 or 10.1.1.10? If you have full internal VPN routeability then you probably want the FQDN to resolve to the internal private IP by setting up split DNS over there as well.

    How does the phone register on 3CX? On the PHONES option, does it register with an external public IP or the internal private IP?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. Don_Zalmrol

    Joined:
    Apr 25, 2012
    Messages:
    45
    Likes Received:
    0
    Hi Brian,

    The FQDN resolves to the internal IP of the PBX.

    Phone is also set to my FQDN.
    How can I check if the phone connects to the internal or the external IP?

    Under options -> restrictions the phone is set to "disallow use of extension outside the LAN"
    Phone provisioning is set to the FQDN and it's routed through my internal interface (PBX IP).

    When I do a call trace, I also see traffic on my internal side going to the PBX and not to the outside.
    Except for the VPN, which is normal.
     
  6. briankayser

    Joined:
    Jul 19, 2016
    Messages:
    49
    Likes Received:
    5
    I need examples - tweak these answers a bit if you don't want to give out your real IPs.

    What is the internal and external IP of your 3CX PBX?
    How is the phone at Site B configured? LAN / STUN / SBC?
    What IP does the phone at Site B register with, in 3CX (in the PHONES section)?
    What is your FQDN?

    Site A - from a PC that gets the same DHCP and DNS info as your phones; ping the FQDN: what does it resolve to?

    Site B - what is the IP of your phone?
    Site B - from a PC that gets the same DHCP and DNS info as your phones; ping the FQDN: what does it resolve to? This PC needs to be on the same VLAN if you use them at Site B.
    Site B - Trace route to the FQDN - it should stay internal.

    Site A - Trace route from the 3CX server to the IP of the phone at Site B. it should stay internal.

    Site B - What phone model are you using?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. dmayer

    Joined:
    Jul 8, 2016
    Messages:
    10
    Likes Received:
    0
    With a site to site VPN, any reason you are using the SBC? Unless you are NATting the VPN tunnels, I would set the extensions to local LAN in provisioning and dump the SBC honestly unless you are doing it for bandwidth reasons.
     
  8. Don_Zalmrol

    Joined:
    Apr 25, 2012
    Messages:
    45
    Likes Received:
    0
    Hi,

    I'm using the SBC to see if it would resolve my audio issue as it was noted in the description of the SBC page for people who are having issues between site-to-site VPN's.

    So I can remove it and use local LAN IP.

    Brian, I will provide you this information tonight.

    From what I can disclose:
    3CX PBX IP: 192.168.98.30 (not real IP)
    External IP: 81.83.22.28
    FQDN: voip.gregoir.be

    A ping from the PBX (Debian Linux server running 3CX v15) to the phone is working with a normal timeout.
    The extension in 3CX is configured to register to the PBX FQDN (voip.gregoir.be) through interface 192.168.98.30

    A ping from a computer in site A resolves to the internal FQDN.

    tracert results show that it stays internal:
    traceroute to 192.168.99.120 (192.168.99.120), 30 hops max, 60 byte packets
    1 192.168.98.1 (192.168.98.1) 0.351 ms 0.371 ms 0.431 ms
    2 * * *
    3 192.168.99.120 (192.168.99.120) 24.373 ms 24.406 ms 24.453 ms


    Site A network:
    192.168.97.0/24
    192.168.98.0/24

    ------------

    Site B is configured as LAN
    Phone registers with 192.168.99.120 (not real IP) and that site only has 1 network 192.168.99.0/24 (No VLANS).

    Site B computer resolves to the internal private FQDN address.
    The phone is a Polycom T42G
     
  9. briankayser

    Joined:
    Jul 19, 2016
    Messages:
    49
    Likes Received:
    5
    Boy... I don't know. If everything is staying internal there should be no reason you are getting one-way audio. Does the 3CX server have more than 1 network adapter? Meaning, is it possible that traffic is coming in one NIC and going out another?

    Have you tried this at Site-B?
    http://www.3cx.com/blog/voip-howto/3cx- ... er-client/

    Even if you are not going through a firewall, it may tell you if things aren't working well. You run it from a PC.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  10. Don_Zalmrol

    Joined:
    Apr 25, 2012
    Messages:
    45
    Likes Received:
    0
    Hi Brian,

    The firewall test passes without any issues (had to whitelist the IP of 3cx stun for the test).
    No secondary IP is configured.

    Only eth0. Perhaps it's a network card setting under Debian?
     
  11. briankayser

    Joined:
    Jul 19, 2016
    Messages:
    49
    Likes Received:
    5
    I'm assuming you've tried the same Polycom T42G at Site-A and it works fine?

    Also, I'm assuming ALL phones have one way audio at Site-B, or is it just this one phone?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  12. Don_Zalmrol

    Joined:
    Apr 25, 2012
    Messages:
    45
    Likes Received:
    0
    Indeed, on Site A all phones work (as well the T42).
    Currently there is only 1 phone in site B.

    The 3CX MyPhone client on my windows computer there has the same issue.
    It's like the RTP ports are not getting through correctly...
     
  13. dmayer

    Joined:
    Jul 8, 2016
    Messages:
    10
    Likes Received:
    0
    Don,

    Is SIP ALG turned off on both routers/firewalls at each location? That causes some fun issues if any SIP helper services are running on a router on either end.

    Also have you tried setting up the phone as a remote extension (STUN) instead of SBC? Maybe disable the VPN connection during this test. Or try the phone/3CX Phone from home using SBC or remote STUN? That should point the issue closer to which side it actually is on.

    You could also change the VPN to only point between Site A's voice LAN to make sure it's not some odd VPN configuration issue.

    Failing this, wireshark is probably going to be needed if the logging on 3CX isn't indicating any RTP problems, sometimes it does.
     
  14. Don_Zalmrol

    Joined:
    Apr 25, 2012
    Messages:
    45
    Likes Received:
    0
    Hi Dmayer,

    On site A I use a SIP proxy to route the 5060-5061 traffic coming from external (outside the LAN and VPN) to the PBX.
    The other traffic is going by a separated rule directly to the PBX (from external to the PBX).

    SIP ALG is only used in the proxy, if you do not use the proxy, then SIP ALG will not be used.
    And if used, it's only on the interface you used it on.

    I will set up an extra VPN to route the VOIP traffic (Voice LAN) directly to my data lan.
    Could be that something funky is going on in the BOVPN from Watchguard.

    I can do the testing this Saturday.
    Will keep you guys posted.
     
  15. dmayer

    Joined:
    Jul 8, 2016
    Messages:
    10
    Likes Received:
    0
    Don,

    While I understand that it should only proxy from external, using the proxy is not a supported 3CX configuration as 3CX (amongst a lot of PBX makers) does not support any kind of SIP ALG as the implementation can differ between manufacturers. You should be using the packet filter with an SNAT for the destination (And also add Any-Internal along with Any-External for source). We have a couple customers using Firebox's and I use Packet Filter instead of Proxy, I've been on the phone with Watchguard for other matters and they always seem to prefer the packet filtering for applications like this. The proxy service also deep inspects the packets, taking them apart and re-assembling them, you do not want this for communications.

    http://www.3cx.com/blog/voip-howto/watc ... -firewall/

    I had a customer with an Asus consumer router that had SIP ALG turned on and hidden and it led to one-way audio on external calls from the SIP trunk provider, I had to update the Asus which exposed the SIP ALG and after I turned it off, it fixed the one-way audio issues.

    SIP-ALG breaks more than it fixes.

    Though we can see what setting up the other VPN does.
     
  16. Don_Zalmrol

    Joined:
    Apr 25, 2012
    Messages:
    45
    Likes Received:
    0
    Hi Dmayer,

    I have changed the rule to a regular packet filter (no more proxies). And pushed it to the top of the rules.
    Set it up as following:

    FROM
    - Any trusted
    - Any External
    - Any bovpn

    TO
    - (SNAT) Any External -> Internal PBX IP



    On my remote site I have set up the same rule and test it, no success. Same issue, phone audio only 1-way (outgoing OK, incoming NOK)

    Then I disabled the rule on the remote site. Same issue, phone audio only 1-way (outgoing OK, incoming NOK)



    I have also tried the other suggestions:

    Provisioning:
    - LAN
    - Remote with SBC
    - Remote with STUN

    Changed the BOVPN routes, will test this tonight.
    Now I have two (active) tunnels, 1 for data and 1 for VOIP.

    Thanks in advance!

    Laurens
     
  17. dmayer

    Joined:
    Jul 8, 2016
    Messages:
    10
    Likes Received:
    0
    Don,

    Both sites use a Watchguard, right?

    Have you been able to test this at another site like your home using direct SIP (STUN), SBC or using a VPN for Local LAN setup? Just want to make sure that is is Site B causing the issue and not Site A. It sounds like you have everything setup correctly.
     
  18. Don_Zalmrol

    Joined:
    Apr 25, 2012
    Messages:
    45
    Likes Received:
    0
    Hi Dmayer,

    Site A is the office, site B is my home (office).
    Both site have a watchguard (XTM550 and XTM750).

    True, like it's set up, it should work.
    Seems like an odd issue with only 1 way audio not working.

    Though it must be a firewall issue as it's audio that isn't received, but then I should see messages in my logs about dropped or denied packets...
     
  19. dmayer

    Joined:
    Jul 8, 2016
    Messages:
    10
    Likes Received:
    0
    Don,

    Does the 3CX App for Android or iPhone work on your mobile while not connected to your home WiFi?
     
  20. Don_Zalmrol

    Joined:
    Apr 25, 2012
    Messages:
    45
    Likes Received:
    0
    Hi Dmayer,

    Tested this this morning.

    3CX app on my iPhone:
    - called to internal extension, no issues.
    - called to external number, no issues.

    The problem seems to be only occurring on site B.
    As the 3CX app connects with site A directly (over a tunnel).
     
Thread Status:
Not open for further replies.