Remote User

[acejavelin]

We do this all the time... literally have hundreds of phones hanging off site from dozens of systems for various customers with all kinds of networking equipment, and rarely have issues.

Make sure the following ports are port forwarded to the IP address of your 5000 (ALL OF THEM!!!)

20001/UDP - TFTP (69/UDP is optional if 20001 fails for some reason)
6800-6802/TCP - MiNET control, basic call control of phones
3998-3999/TCP - SAC, application and button control of phones
50098–50508/UDP - RTP Audio Inbound from 52XX/53XX sets
6004–6261/UDP - RTP Audio Outbound from Processor module (even though they are outbound originating, forward them)

This is all that is needed for a basic 5000 controller with remote 53xx sets for port forwarding. Having the ports in bold above forwarded properly are all that is required for the phone to boot up properly, but it won't make a usable call yet though until we port forward the last 2 ranges so the audio works. Then you must set the public IP address that the 5000 uses in the IP connections for the processor. Then in each phone's IP Settings change Native to NAT, NAT may work inside your LAN as well depending on your network configuration, or the audio maybe broken on one or both directions.

We have seen issues where IPS/IDS in some firewalls prevents phones from working or causes them to disconnect. We have also had a LOT of problems with customers using Netgear routers, the way they do port forwarding is for lack of a better word, broken, and remote phones don't work properly on many router models. If the phones are failing to boot up, one of the first three entries in bold is not working properly.

[edtomfish]

So I got the phone connected fine to another 250.

I captured its traffic and what it does: 

Tftp ok
Tries port 6801 no answer
Tries port 6802 no answer
Tries port 6800 connection made, phone works


Compared to the one we're having issues with the phone
Hits tftp ok. Then it tries 6801 no answer from the server and just Kees trying over and over. 

Why is the phone trying the next two ports on one server (and working) but not another?

[acejavelin]

Asking why isn't relevant, it is how the phone is working, might be the system telling it to act differently for some reason because if it's source IP or the phone recognizes it's in a different subnet that the controller, I don't know and tech support probably couldn't answer it either, it would require an engineer... The point is you need to do the port forwarding as required.

[edtomfish]

Port forwards are setup as they were 2 years ago when this was originally installed and working. 

As far as I can tell anyway.  Trying to get a look at the traffic there.  The logs show the forwarding is ok.

[acejavelin]

Port forwards are setup as they were 2 years ago when this was originally installed and working. 

As far as I can tell anyway.  Trying to get a look at the traffic there.  The logs show the forwarding is ok.

Then something has changed... the ISP, the router firmware or configuration, etc... if traffic won't come though on a certain port, you need to fix the router or ISP (don't kid yourself, we have seen several ISP's block certain ports for really stupid reasons or their IDS/IPS does it automatically). Don't over complicate it. Sometimes this is as simple as someone added a conflicting rule in the router for a different service.  What router are we dealing with?

Honestly, a lot of times when I see this elimination is easier than investigation... take a slow time in the evening and configure a different router (I carry an Asus RT-N66U in my truck for such things, but the model doesn't matter as long as it's decent, previously I used a Linksys WRT-54G)  and configure it with the static IP, LAN address and port forwarding and test again, if it works, it's a router issue, if it doesn't then at least you eliminated the most likely cause.

[edtomfish]

Leaning towards ISP now except they are saying nothing.  Apparently close to the time when remote phone went down there was a complete voice outtage.  Router is a watchguard FYI. 

[edtomfish]

..on top of that the router is the only thing I can guarantee hasn't been changed.  I can't say same for the mitel box or ISP gear.

[edtomfish]

Still convinced the ISP is the issue.  The issue seems to be packets being modified (sounds slightly crazy) enough that the phones aren't functioning properly.  I've captured traffic at a few different points in the path between server and phone and here is what I have:

The following packet samples from 4 different points between phone server and remote phone...  (.46 is my public where the phone is, .157 is the public of the server, .106 is the phone private)

From the phone server:
19           0.396725000       10.0.0.210            xx.xx.xx.46         TCP        60           6801→6920 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
 
From our internal firewall:
5275       2.655164              xx.xx.xx.157       xx.xx.xx.46         TCP        54           6801→6944 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
 
From the Spirit Adtran:
14           35.041900634     xx.xx.xx.157       xx.xx.xx.46         TCP        64           6801→6988 [RST] Seq=1 Win=0 Len=0
 
From the phone in my home office:
107         70.391494000     xx.xx.xx.157       192.168.0.106     TCP        60           6801→6924 [RST] Seq=1 Win=0 Len=0
 
 

For comparison, here is what the traffic looks like at the phone when the phone is connected to another Mitel server at a different location using a different ISP:
132         59.471738000     xx.xx.xx.243                192.168.0.106     TCP        60           6801→6996 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0


So the best I can tell - when 6801 isn't open the phone tries 6802, when 6802 isn't open, it goes to 6800 where the connection works.  This is how these phones behave on the LAN too.   

So the issue is now with the packets ... being sent from the server with BOTH THE ACK and RST flags set all the way until they leave my firewall.  Looks like after they leave the ISP adtran they lose the ACK flag and only the RST flag is sent and this is all the reaches the phone.  I don't know, but I'm assuming that the phone is looking for an ACK, RST before attempting the next port.

This is my theory and I'm having a great time trying to convince the ISP.

[Tech Electronics]

edtomfish,

So, this is interesting although my thoughts on it are purely conjecture at this point.

An RST/ACK is just combining two packets into one similar to a SYN/ACK. It is acknowledging that it received the 6801 request for SYN with an ACK and then also notifying the phone that the connection was closed with the RST.

Now when the phone gets an RST packet in the middle of the 3-way handshake it is telling it that the MiVO-250 has rejected the connection or is unavailable to communicate further for whatever reason. This may be why it is resending the SYN again for 6801 instead of going on to 6802.

I wonder if the Mitel phone is expecting the ACK to determine if the packet was received properly before it continues on to the next port?

What if you block ports 6801 and 6802 on the firewall and just open up 6800?

Interesting,

TE

[edtomfish]

As backwards as it sounds it makes sense.  I'm excited to try this tomorrow.

[edtomfish]

No dice.  I haven't looked at the traffic but I'm guessing the firewall simply sends the RST flag and the phone keeps trying that port. 

So the little bit of info I've found shows that ports 6800-6802 are for signaling? and that 6801/6802 are for secure and 6800 is open/insecure.  As a work-around, I'm now curious how I can turn on encryption and try to force it to use 6801?

[Tech Electronics]

edtomfish,

The ports 6800-6802 are the MiNet protocol for basic call control. The port the extension uses for this connection may be random, but the MiVO-250 requires the use of those specific ports that is why you are seeing the other ports showing up on your trace.

Thanks,

TE

[edtomfish]

So the server ports are this specifically:

6801 is Minet-SSL
6802 is Minet-AES
6800 is Minet - (open/unencrypted)

It makes sense that the phone would try the two secure options first and then finally settle on the last one if those options arent setup on the server... so I guess my question is - where on the 250 can i enable SLL and/or AES?  if thats where the phone tries first and if i can get the server to answer there - that might be a workaround to my issue.  because even on my lan the phones are trying 6801. 6802 and finally settling on 6800.  im not sure if im conveying my line of thinking that well.

[Tech Electronics]

edtomfish,

There are no settings, that I am aware of, in the MiVO-250 to modify how it works with MiNet. I just looked in my lab system and I can't find anything obvious in On-Line Monitor or on the Web Interface. There may be something under the command line interface, but you would need Mitel to explain how to do that.

I think at this point I would try to temporarily bypass the Adtran with some other Layer 3 device and see if it fixes the problem.

Sorry,

TE