Remote user issues

[mruffin75]

Hi All,

We have an issue where remote users of the webclient portal, cannot hear audio on their calls (both directions).

I ran Wireshark on a laptop, connected both internally and externally while trying to make a call, and found that in both instances, the STUN request is trying to communicate with the internal IP address of the 3CX server.

Obviously this won't work with people who are trying to connect to the 3CX server from outside our network.

The only thing I can find that may be causing this, is that all "outside" connections to 3CX (Desktop App, Web client, Mobile App), are listed as coming from the router IP address in the Phones list, rather than their actual IP address. I'm assuming at this point, the server assumes that since the IP address that they're trying to connect with is "internal", then it gives them the internal IP address of the STUN server rather than the external address.

I'm pretty sure this is a routing issue with the firewall (Fortigate), but just double checking. If anyone has had this problem before with a Fortigate, I'd be especially interested to hear from you!

Michael

 

[Saqqara]

Does the firewall pass without errors

have you setup portforwarding for 3cx tunnel port (udp port 5090)

 

[mruffin75]

Firewall passes with flying colours (no errors).

And yes, 5090 is setup.

I think the problem lies with the fact that external clients (notably the webclient) try to contact the internal IP address of the STUN server, instead of the external IP. This works for internal clients, but anyone connecting remotely, there's no audio.

 

[Evolute IT]

First of, in Phones, you should see the WAN IP always when it's in STUN. That's what the Register contact header has. The STUN server is usually either a set one by 3CX or the PBX itself. In both cases, DNS is needed to resolve the IP.

For the audio issue, when using the Webclient, it should work as long as they're using the https FQDN.

 

[JohnS_3CX]

the STUN request is trying to communicate with the internal IP address of the 3CX server

Are you guys using a VPN to connect the remote workers to the office?

 

[mruffin75]

First of, in Phones, you should see the WAN IP always when it's in STUN. That's what the Register contact header has. The STUN server is usually either a set one by 3CX or the PBX itself. In both cases, DNS is needed to resolve the IP.

For the audio issue, when using the Webclient, it should work as long as they're using the https FQDN.

The register IP address is always coming from the router. On another 3CX system, the IP addresses of remote devices (phones, webclients etc.) are always the IP address of the device.

 

[mruffin75]

Are you guys using a VPN to connect the remote workers to the office?

Nope. Straight port forwarding, but the configuration of the router is very complex as it's a large network.

On doing a packet capture on the 3CX server itself, it seems that all connections seem to be coming from the firewall, and not the individual devices, so it's proxying the connections or something.

 

[JohnS_3CX]

Re-writing the source IPs will definitely cause problems for remote users.

The PBX treats LAN and WAN connections differently from each other, so if it's being fooled by the firewall I would expect issues to pop up.

 

[ThomasD_3CX]

I ran Wireshark on a laptop, connected both internally and externally while trying to make a call, and found that in both instances, the STUN request is trying to communicate with the internal IP address of the 3CX server.

When the 3CX WC is connected remotely to the 3CX System, but you see in packet capture that the STUN requested from the 3CX client to the 3CX System are forwarded to the local IP address of the system (not the public as it should have), indicates that the HTTPS traffic from the client to the 3CX system, are received on the system from a local IP scheme (RFC 1918). The remote 3CX client's requests should be received on the 3CX system from the original public IP address of the 3CX client site.

If you run a simultaneous capture on the 3CX System and 3CX client, and make a call, if you filter the system's capture with the public IP address of the remote site, can you see any traffic at all ?
If not try filtering with the local IP address of the default Gateway, on 3CX system's side, and the web server port used by your installation (default 5001 / 443) and you will probably see some traffic, by using this filter.

If this is the case your gateway either proxies the traffic and/or a NAT policy is misconfigured (translating the source IP to the gateways interface) and/or Sip ALG (or similar service on the firewall) or similar configuration related to the above, so the remote client's requests are hitting the 3CX System from a local source IP scheme - not the original public source IP.