Moved from NAT pbx to internet ip, lost nat phone communication

[TimGuyUK]

Me again. So we moved our fusion server from dev to live testing. With the current situation we wanted to change the office over to fusion so we can have staff at home. The server was originally behind a MK router NATed, it took some time to get it working (with help of yourselves) but it was working perfectly

Phone <> nat <> internet <> nat <> fusion was perfect for all calls.

Weve now moved the pbx over to production servers and we have the chance to give it a real internet interfacing ip address. Accept it doesn't work, well it does sometimes.

Now we are Phone <> nat <> internet (same subnet) <>fusion

At the moment the yealink phones are behind a MK firewall with the MK internet ip address on the same range as the fusionbox. GS Wave apps on cellphones work as well as GS Wave on my home BB but I cant get anything behind the firewall working inbound or internal to internal (out bound to sip trunk is ok as is external to ivr/fusion terminated). I haven't tried a distance yealink phone well away from the office, ill try that tomorrow. The issue appears to be that the communication is trying to use the nat internal ip address of the phone to communicate. ALG and all that jazz is all off.

I see there is split opinion with the gurus on the forum about using a stun server or not. This pbx will be multi tenant with customer configurations on it. I want it to work for everyone not just for our office. Should I look at a stun server? obviously some of you do and some of you don't. Or do I put the MK router back and run it nat to nat again (all be it being another point of failure)

Fusion must work with no nat pbx but I cant get it going.

Tim

 

[TimGuyUK]

How do I explain this:

So

Phone 192.168.1.10 NAT <> Phone Router External IP 1.1.1.1 <> FusionPBX 1.1.1.2 (So same internet ip range) - DIDNT WORK
Phone 192.168.88.2 NAT <> Another Router Test External IP 1.1.1.3 <> FusionPBX 1.1.1.2 (So same internet ip range) - DIDNT WORK

Got frustrate, went to another site
Phone 192.168.2.10 NAT <> Phone Router External IP 2.2.2.2 <> internet <> FusionPBX 1.1.1.2 - WORKED (Hurra)

Went to another site
Phone 192.168.3.10 NAT <> Phone Router External IP 3.3.3.3 <> internet <> FusionPBX 1.1.1.2 - WORKED (Hurra)

Fine, so my issue is same subnet internet routing, Ill go back and start working on the problem.

SAME AS ORIGINAL TEST to start fault finding.
Phone 192.168.1.10 NAT <> Phone Router External IP 1.1.1.1 <> FusionPBX 1.1.1.2 (So same internet ip range) - BLEEDIN WORKED!!!!!!
Tested over and over again, WORKED!

What a nightmare. Im no further forward. At somestage its going to fail again as Ive done nothing to the configure during these tests.

On the basis it is something to do with same ip routing to NAT has anyone got any suggestions?

Tim

 

[ewdpb]

Hey @TimGuyUK ,

Working out these issues is a nightmare for there are too many moving parts. NAT alone is not enough for your phones to work reliably, user's home routers sometimes are to blame. In those situations I just tell my customers (and my own people) to use a VPN. You can simply setup pfSense at your office or in the cloud (providing you have a FW or router able to create some sort of VPN tunnel: IPSEC, OpenVPN, etc.) and then have people connect using the OpenVPN.

Another alternative is to use a SBC to front your freeswitch. That really makes it easier: OpenSIPS or Kamailio are afordable alternatives.

While I believe many people uses freeswitch fronting the Internet, I have found it too complicated to deal with, not to mention the secutity challenges.

Sorry I am not providing any fix for your problems but sometimes looking at different alternatives is the actual fix.

 

[Adrian Fretwell]

@TimGuyUK On the face of it, I can see no reason why your setup is not working or why it should work intermittently.

The only sure way to get to the bottom of this and understand what is going on will be to get some packet captures and examine them in Wireshark or with Sngrep. You will see this same advice given time and time again on this forum. I generally prefer to use tcpdump and Wireshark because I can look at what is going on in other protocols such as STUN ICMP etc.. Don't forget that Yealink phones also have a packet capture facility.

We are in the UK, we have Fusion on public IPs in data centres, and most of our customers are on simple ADSL broadband connections behind NAT (with static external IPs where possible). Send me a PM if you want to talk about actual IP addresses / packet captures etc.

Bear in mind there are three types of NAT in common use: full cone NAT, restricted cone NAT, and port restricted cone NAT. A fourth type of NAT called symmetric NAT, is also available but its use is much less common.

We do run our own STUN servers and we do put these into the configuration on our Yealink phones. STUN allows devices to detect and traverse NATs that are located in the path between two communication endpoints, by making the devices aware of the IP address and port numbers they are presenting to the outside world on the other side of the router or firewall. STUN will not work with a symmetric NAT because this type of NAT allocates a different randomly selected IP port for each connection which a device makes.

If you choose to use STUN, most VoIP devices will require the name or address of a STUN server in their configuration by default and, in normal use, will query the STUN server from time to time to check the IP address and port number that they are presenting to the outside world. Yealink phones seem to perform this operation every three minutes.

If a packet capture shows that every time the phones contacted the STUN server, the STUN server returned a different IP port number for the same device. This would suggest that the phones are located behind a symmetric NAT.

A further indicator of Symmetric NAT can be found with Yealink phones. When the Yealink phone queries the STUN server, three minutes after initial registration, the result indicates that the phone has been moved to a different external IP port from the one it was on when it registered. At this point the phone de-registers and then re-registers with the new port information in its Contact headers. A brief "No Service" message appears on the screen while this de-register/re-register process is going on. This can often appear as a seemingly random working / not working scenario especially to someone trying to call the phone..

RPORT is another very useful tool in the battle with NAT and is encapsulated in RFC3581 (Symmetric Response Routing) Yealink phones support it. This allows the server handling the request to not only determine the source address that the request came from but to also record the source IP port number in a parameter called "rport" which is attached to the topmost Via header field value of the request.

 

[TimGuyUK]

Thank you for your indepth responses that's very kind of you to take the time to reply.

Because of lack of time Ive returned the Fusion box back to NAT behind a firewall(Mikrotik) all be it in the same ip subnet location as the Office. Its now working. We have had to send most of our staff home now and so down time is limited.

I will return to this at some stage, maybe with a second fusion.

Thank you.

Tim