External VOIP Phones connecting back to Office - No Audio

You have to look for audio ports too, and the configuration of NAT Traversal in the phone. I had this problem 5 years ago with 3CX Server.

The server also have a rule to allow external or outside phones.

I deletet those rules in my firewall, because i dont use it anymore, but if i find any backup i will write it down

The NS700 PABX already has those handsets and extensions setup as external in its internal config. Its network settings are manual and the IP, Subnet and Gateway all match the required subnet settings and point to the Layer 3 switch that handles all internal routing. I'm on the Web Interface now from home - so I know my NAT/Port Forwards are OK and hitting the PABX OK ... this is starting to drive me a little nuts ;) It SHOULD be working from what I can see!

Hrmmm ....

Internally its vLAN 30 ... from the PABX I can ping the gateway (the Layer 3 switch) on its vLAN 30 interface - 10.0.30.254. From the PABX I can ping the internal interface of the SG230 - 10.0.10.250. From the PABX I can even ping the switch at a remote site connected to the SG230 by a RED15w on vLAN50 - 10.0.50.1

I've setup the two RTP NAT rules:

DNAT: Any - 16000:16511 - 3rd IP on 2nd Internet Connection = Destination: PABX Card 1 (autocreate firewall rule)

DNAT: Any - 16511:17023 - 3rd IP on 2nd Internet Connection = Destination: PABX Card 2 (autocreate firewall rule)

I tried creating two SNAT Rules:

SNAT: PABX Card 1 - 16000:16511 - Any (autocreate firewall rule)
SNAT: PABX Card 2 - 6511:17023 - Any (autocreate firewall rule)

Didn't make any difference.

Then I had a thought about the two Internet connections that are load balanced - maybe I need to add a Multipath rule since the External IP I have allocated to the PABX is on Connection 2. So I created:

VOIP Rule: vLAN 30 - Any - Any - Connection 2   (vLAN 30 is defined as the 10.0.30.0/24 network on the SG230 - I have setup the Static Route (vlan30 - Interface Internal) and 30.0.10.in-addr.arpa - to my internal Windows DC's that are running as DNS Servers) this is the exact same setup I have for ALL of my internal vLANS I run - which are working have been working fine like this for years.

Open to any ideas, suggestions, pointers, slaps across the back of the head!

What do you learn from doing #1 in Rulz?

Cheers - Bob

Cheers for the reply Bob, apologies for the delayed reply - it was a Public Holiday here yesterday and I've only just got back in the office!

The Firewall logs aren't showing anything at all. I sit there watching the Live Firewall logs when calls are being made and I am not seeing anything being actively dropped/blocked.

Actually, if you read #1 closely, you'll see that I was more interested in the Intrusion Prevention log... [;)]

Cheers - Bob

LOL, missed that bit. Absolutely nothing at all popping in the IP logs. I just made a call to the handset at my place - nada in the IP Log and nothing dropped in the Firewall logs. 

This is starting to drive me a little nuts! One tiny little thing somewhere is screwing it ... 

Yeah, it looks like there's no escape from having to use tcpdump.

Cheers - Bob

I'd scour through the NAT settings on your PBX. The only reason I say this is because any SIP system I've worked with has needed these changes in order to have audio passed to external extensions. The IP's I gave in my example above obviously do not apply but there might be an equivalent option(s) for your Panasonic system and maybe even the handset as well. Much like Asterisk. You have specified the NAT - Fixed Global IP Address in the Panasonic web console?

This might be the equivalent of asterisks "externip" option:

Indicates the IP address that will be used as the source IP address for all SIP messages when NAT is specified.

Where as my post above is about the "localnet" option

Hosts falling within the network ranges specified by the localnet option will be excluded from any NATing efforts by Asterisk. As a result, the source IP address within the SIP requests/responses will use the internal IP address of the network interface associated with bindaddr .

Thought I'd touch base with this ongoing issue. 

I submitted an official Support Request with Sophos last week but haven't had much luck/response with Sophos other than two emails suggesting what I have already done, and showed them the screenshots for ... awaiting another response sometime tomorrow ...

Working remotely after hours (its after midnight here now!) I've turned logging on on my Firewall Rules just to see the ACCEPTED packets, as well as the Dropped.

When I call from my mobile to my Direct Dial Number of my phone sitting beside me it makes the call and connects fine everytime. The Firewall shows:

1st Call  

And I had audio ONE WAY. Speaking into my mobile it was being received on the phone extension. No audio was going from the extension back to the mobile phone. There was only this single ACCEPTED LINE referencing my IP here at home (61.68.6.236) and its going to the DSP1 card on the PABX on the 16000 Port, as its supposed to. There were no other ACCEPTED packets from my IP at all, no DROPS either.

2nd Call  

This call was identical to the first, audio from my mobile being received by the remote phone handset, no audio back the other way. Again, only a single ACCEPT entry in the Firewall, no DROPS.

3rd Call 

Here is a difference. This time NO audio was sent or received ON EITHER END. At all. I ended up hanging up after 20 seconds. ACCEPTED packets from my IP to the Phone System continued the whole time.

4th Call  

Identical to Call 3, no audio either way

5th Call 

Identical to Calls 3 and 4, no audio either way again, lots of accepted packets int eh log and no DROPS at all either from my IP, to my IP or to/from the PABX IP's.

As mentioned earlier - no entries at all coming up in IPS and ATM while calls are active.


In regards to the PABX - the only networking components I can see in the Web Admin Console are your basic set DHCP or Static, and Static is selected and the Details manually entered are:

IP: 10.0.30.250
Subnet: 255.255.255.0
Gateway: 10.0.30.254 (The Dell Layer 3 Switch - same as every other vLAN)
DNS: 10.0.10.51 and 10.0.10.52 - our two internal Windows 2016 DC's running AD, DNS, DHCP

DSP1 Card: 10.0.30.251
DSP2 Card: 10.0.30.252

And thats about it ... nothing about NAT, NAT Traversal or anything else that I can see. 

Again, any comments, suggestions, ideas etc are greatly appreciated!!!

Hopefully Sophos will get back to me tomorrow with some suggestions that I already haven't tried!  ;)

Do a preentscren of the phone configuration page (hide sensitive data)

Something its wrong because in the logs i see private IP not your external IP

Agreed with oldeda - the traffic is not even hitting the UTM - tcpdump would likely confirm that.

Cheers - Bob

Cheers lads - I will be doing some packet tracing from the Phone System outwards shortly, just getting Wireshark installed onto a laptop ...

I had Richard from Sophos 'remoted' in in the past hour or so going through the UTM. I showed him all my PABX and Dell 6448 Configs and settings etc and he did jump into TCPDump on the UTM and we could see the packets from my external handset hitting the firewall on the correct external IP and the Accepted Packets going to the Internal IP of the PABX and the right Port Ranges (that match the Port Forwards) - but again only from Outside In. Nothing is going from the PABX outwards according to logging ... but the annoying thing is - occasionally audio IS getting to the remote handset yet there is no DROPPED or ACCEPTED packets going through the Firewall?! Only my external IP to the Internal IP of the PABX!

Anyways, I'll do some packet sniffing (I'll mirror the PABX's port on the switch) and see whats going out of there and where its going to to see if I can suss anything out there.

Richard has escalated the case with Sophos Support to Level 2 - I'll report back any further progress and or findings ;)

Cheers again for the assistance/advice so far!  ;) 

Cheers lads - I will be doing some packet tracing from the Phone System outwards shortly, just getting Wireshark installed onto a laptop ...

I had Richard from Sophos 'remoted' in in the past hour or so going through the UTM. I showed him all my PABX and Dell 6448 Configs and settings etc and he did jump into TCPDump on the UTM and we could see the packets from my external handset hitting the firewall on the correct external IP and the Accepted Packets going to the Internal IP of the PABX and the right Port Ranges (that match the Port Forwards) - but again only from Outside In. Nothing is going from the PABX outwards according to logging ... but the annoying thing is - occasionally audio IS getting to the remote handset yet there is no DROPPED or ACCEPTED packets going through the Firewall?! Only my external IP to the Internal IP of the PABX!

Anyways, I'll do some packet sniffing (I'll mirror the PABX's port on the switch) and see whats going out of there and where its going to to see if I can suss anything out there.

Richard has escalated the case with Sophos Support to Level 2 - I'll report back any further progress and or findings ;)

Cheers again for the assistance/advice so far!  ;) 

Have you searched in Google for your PBX "Nat Traversal" (not port forwarding etc)

If not you are in the wrong forum

Bye

Still awaiting Sophos Support to contact me again on this case. Just fired off another reminder after my last reminder a week ago.

Will advise outcome

Well after weeks of screwing around with this my hand is getting forced to dump Sophos across the entire network :( 

We've had 2 Sophos Engineers remote in and capture live data traversing the UTM then shrug their shoulders after confirming everything I have already said to them and sent wireshark traces and screenshots of Live Firewall logs. The phone provider has sent out 3 different network specialists, I've had a mate of mine (also a network security specialist) plus my weeks of research and testing and none of us can see why the voice traffic is not traversing correctly through the SG230. We can see all the packets hitting the PABX via the allocated external IP and different port ranges and we can see them all heading back out but they never arrive at their destination. I've tried every Multi Path rule I can think of, DNAT and SNAT rules, NAT Masquerading, breaking the Link Balancing etc and it just will not work. 

Its a pain due to all the IP's I have, services running, RED sites connected etc but I'm getting a shitload of pressure to get the remote phones working ASAP :( 

Cheers for the help lads.

Hi Dread,

I run three different PBX systems here in my office,I work for a telecoms provider, and have no problems with the Phones on any of the systems, except when you have a router (at home) that doesn't like SIP ... for instance had a Virgin Super Hub (I had this ISP a few years back), had to disable SIP ALG on the firewall (and then they go and update the router firmware which  switches SIP ALG on.. ).

I have found default routers like BT super (un-helpful) hub absolutely hates SIP (strange for a huge ... pain in the harris .. telecoms company..lol), in fact a lot of ISPs do not like you using SIP based products (or even your own routers for that matter...) on their internet (go figure).

check your router out and look out for SIP ALG, also check on your home ISP providers forums for SIP/VoIP based issues...

If you have a BT Super Hub (or any BT hub/router), get another router.

Sky Q Router - there's a problem

TalkTalk - they do not like you using SIP through their router (but there are documented ways around this).

I hope this helps

Jason

Cheers for the reply Jason

We've tested from about 5 different ISP connections and modem/routers now, including the Telco engineers soft phone and 3G Dongle while he was sitting beside me here in the Office. It's definatly not the remote end that is the issue here.

I'm pretty sure its a NAT issue or something to do with the Multipath rules not actually working as intended.

As an example, the original deployment of the new PABX was using our existing ISDN lines until their new SIP trunks could be provisioned on a new 2mb up/down service on a Cisco they installed into the comms room. On Monday they were unable to register the services back to their end - I could see the 15060 traffic leaving the PABX and going out to their IP but there was no evidence at all of return traffic from them. Change the gateway on the PABX to their 2mb up/down connection and it registers instantly. The ISDN service was ported to the new SIP trunks yesterday so we've left the PABX pointed like that as it just will not register/work at all if it goes through the SG230.

I was thinking about setting up that 2mb up/down as a third Internet service/interface on the SG230 but I just have zero faith at all at this stage that it will work and I am already getting enough grief from management and remote site staff as it is I figure its just far easier to go with a solution that will just work out of the box - even if it means dumping the web filtering/reporting and going back to a 3rd party mail filtering service. I'll miss the RED devices I've put in remote sites but I can replicate that with IPSEC VPN's between the sites 'the old way' and once the remote phones are working they will go via the internet anyway back to the PABX.

It just frustrated me that this is like 90% working and its one thing blocking everything and I can't figure out what it is, nor can anyone else :(