Help - Sophos XG v17 3CX Outgoing call issues

[techguard]

Hi there - I have setup a new Sophos XG105w at a client and I am having issues with calls dialing out over their 3CX system. The 3CX firewall checker passes.

In some cases the call wont even try and dial out when dialed. 'Pls Hang Up' or 'Not found' are noted on the phone displays and no connection.

Initially when we set it up - the SIP helper was disabled by us as we read that in the Sophos KB and here however we were getting no audio on the calls - so we enabled it again and the audio came back. Sophos support said the sip helper must not be enabled on the VOIP provider side and so we had to enabled it on the XG firewall.

I have one rule setup with all the 3CX ports forwarded from anywhere (for the moment) on the WAN to the internal IP of the PBX that sits behind the firewall. I have another rule setup to allow the PBX to talk out on the WAN to anything over any port.

Some calls ring through - others don't. Did a packet capture on the XG but can't see where its going drop. Did a drop-packet-capture command as well on the console with no results.

If someone has a 3CX behind a Sophos XG can you please share the rules and relevant settings you have in place for it to work. At my wits end here trying to figure it out.

 

[techguard]

Hi all - back again - so had last 1.5 day of testing. Some issues were related to incorrect configuration of the 3cx by VOIP provider and SIP Provider. The 503 issue was due to the SIP provider not assigning the correct number of simultaneous calls. The "target endpoint cannot be built" error was down to an incorrect outbound rule which has been resolved. "PBX to deliver audio" setting was enabled on the handsets which has been disabled by the VOIP installer. The last remaining issues appear to be firewall related. For some reason calls outbound (only) are intermittently not getting mapped correctly. About 90% work correctly with 10% not working correctly.

The two remaining issues are:
Issue 1: Intermittently on outgoing calls – there is no audio at all on either end - firewall mapping translation error appears to occur in this scenario. See attachment.

Issue 2: Intermittently the outgoing call doesn’t make it out at all – message appears instantly on phone that says “Pls hang up” – 3CX shows the call as “not answered” and the same firewall mapping translation error appears to occur in this scenario. - See attachment.

I have moved back to a WAN-LAN port fwd rule with reflexive ticked as I wasnt sure if unticking it and setting up a lan - wan rule in its place would do the same thing or cause more issues?

We disabled SIP ALG again and then the 5060 handshake between the 3CX and SIP provider was getting mapped incorrectly (same port 1024 as in the issues above) and 90% of outgoing and inbound calls didn't work and no audio, so we enabled SIP ALG again as there is less issues with it enabled.

If anyone has any ideas it would be much obliged. I have port forwarding rule attached.

 

[i3]

If I am following the attachment logs correctly, it appears the three "no audio" examples in the attachment seem to be outbound attempts, however, the "successful" call example is of an inbound call. Would it be possible to get failed a completed call examples in the same direction?

Also, did you create the catch-all outbound rule I mentioned the other day?

 

[Stevetritton]

Hi
On the XG I have the SIP ALG disabled.
I then have 4 rules to open up the required 3CX ports - See attached..

This is much easier to do on SG than XG but above work with TalkTalk SIP trunk in UK which uses IP address only.

Hope this helps

Steve

 

[techguard]

If I am following the attachment logs correctly, it appears the three "no audio" examples in the attachment seem to be outbound attempts, however, the "successful" call example is of an inbound call. Would it be possible to get failed a completed call examples in the same direction?

Also, did you create the catch-all outbound rule I mentioned the other day?

Hi i3 - thanks for your message. Sorry for the delay. I have been monitoring the situation over the last two days since the 3CX provider made another change to the phones. Two of the phones had "deliver audio to the pbx" ticked. There has been no issues since.

It seems the sophos logs show in many cases "LAN-WAN" for nearly all inbound and outbound calls bar an odd one here and there.As the rule I have is reflexive maybe this is why I'm unable to determine an outbound call vs an inbound call.

The 3CX installer hasn't setup a catch all rule by the looks of it so far. The system is working though it would appear without issues over the last two days. I just have one port forwarding rule setup which forwards the ports to the 3CX (wan to lan) - the rule has reflexive ticked and also NAT setting in the rule is set to masquerade.

I'll have to split up some of the port forwarding rule into separate rules to get more granularity.

The 3CX provider asked me to forward RTP ports 9000-9500 but the firewall logs only seem to show me lan to wan source ports in the 7000 range so I'm not sure whether the SIP provider is generating these ports (after the initial handshake over UDP 5060) or if the 3CX is generating these.

Anyone have any ideas where the RTP ports are configured on the 3CX system?

 

[techguard]

Hi
On the XG I have the SIP ALG disabled.
I then have 4 rules to open up the required 3CX ports - See attached..

This is much easier to do on SG than XG but above work with TalkTalk SIP trunk in UK which uses IP address only.

Hope this helps

Steve

Hi Steve

Thanks for that - good too see how you did it - I just have all the ports in one rule.
Do you have those wan to lan port forward rules set to be "reflexive" or do you have separate lan-wan rules for the related outbound traffic?

Thanks

 

[techguard]

Ok so a bit more digging and I found this.

From what I have found there are two sets of ports listed in the 3CX system.
https://www.3cx.com/blog/docs/3cx-phone-system-parameters-table/

By default Ports 7000 to 7499 are configured in the parameters table of the 3CX server settings for “internal calls”.
By default Ports 9000 to 9049 (by default) are configured in the parameters table of the 3CX server settings for “external calls”.

The 7000 ports are the ports I can see hitting the firewall. So it would appear that the 3CX system is using/generating these ports to talk with the SIP provider for all inbound and outbound (external or internal) calls which are answered or dialled internally.

As a test I connected with a remote soft client on separate public ip and made a call there via the soft client from my PC but the 7000 port range still showed up in the logs.

So I’m not sure what scenario is supposed to generate the 9000 range of ports I was told to forward?
Any ideas?

The SIP provider users RTP ports 30000 - 65535. I might be missing something glaringly obvious here but I'm trying to figure out when an outbound call is made and the 3CX generates a port in the 7000 range - how does it know to send it to the SIP provider in their RTP 30,000 range as thats not specified in the 3CX system.

Could it be the case that the SIP provider first initiates the RTP session regardless for outbound and inbound calls and the 3CX system just replies with a source port in the 7000 range and sends back over the same RTP port the SIP provider generated?

 

[NickD_3CX]

This happens on a few occasions and truth be told, it is hard to spot... Good catch!

Anyway, indeed 3CX has 2 port ranges 7000-7500 for Local LAN devices and 9000-9255 for External Devices/Providers.

The way 3CX separates Local LAN and External devices can very, but it all comes down to the IP address that 3CX receives information from, or the IP address that entity is requesting a reply on.
If this IP is RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), the in the SDP 3CX will request audio to the Local ports, if not to the External ports.

We have seen on multiple occasions that SIP ALG, on incoming INVITE messages from providers changes the IPs to RFC1918, causing 3CX to "flag" the provider as a Local entity thus causing it to use different ports.
To check this, run the Firewall Checker and see if it passes the SIP ALG test.

If this passes, then you need to check the actual SIP INVITE messages to see if this is happening. Although and off chance, it could be a mistake that is actually being generated from the provider's side.

One important thing to note is that this check is not done on every single call. Calls may be working fine using ports 9xxx, then the "mistake" happens once and all subsequent calls will be using 7xxx ports. 3CX "remembers" that one Local IP response, especially when it comes to providers, as it is highly unusual a provider to switch from local to remote...

 

[techguard]

This happens on a few occasions and truth be told, it is hard to spot... Good catch!

Anyway, indeed 3CX has 2 port ranges 7000-7500 for Local LAN devices and 9000-9255 for External Devices/Providers.

[snip]

One important thing to note is that this check is not done on every single call. Calls may be working fine using ports 9xxx, then the "mistake" happens once and all subsequent calls will be using 7xxx ports. 3CX "remembers" that one Local IP response, especially when it comes to providers, as it is highly unusual a provider to switch from local to remote...

Hi Nick thanks for the reply and insight that is great info to have. I'm trying to figure out (since I don't have the 7000 port range forwarded on any firewall rule ) how are the inbound/outbound calls making it through using these ports forwarding rules.

Doing a packet capture of inbound call - I can see that in the UDP port 5060 packet information - the SIP provider provides the RTP port in 30000 range which 3CX then replies back to via source port in the 7000 range. Then the UDP packets sent in and out after that over those ports are logged in Sophos against the same port forward rule as the 5060 port even though there are no firewall rules that denote what to do with wan to lan packets that have destination port in 7000 range. Must be that the firewall knows its the same conversation that it logs the traffic against the same rule.

I have split the firewall rules into two port fowarding rules
1. 5060,5090 TCP UDP wan to lan 3cx
2. 9000-9500 UDP wan to lan 3cx

Whats puzzling now is that the firewall is logging some traffic against rule 2 above even though the traffic doesnt seem to see any ports in the 9000 range as the logs list ports in the 7000 range. Most callss get routed via rule 1.