Mitel Forums - The Unofficial Source
Mitel Forums => MiVoice Office 250/Mitel 5000 => Topic started by: edtomfish on May 19, 2017, 04:45:55 PM
-
So I'm having a heckuva time getting a 5330 phone to connect from my home.
I've got a public IP just for this purpose and firewall is forwarding all ports to the 5000.
On the Phone, I've tried two ways:
under remote worker gateway - entered the public IP
and
under manual IP4 settings, added the public IP under TFTP server and ICP
both of these then hang at "contacting server".
I can see the traffic at the firewall - its allowed 20001 UDP followed by a bunch of 6801 TCP ...
Whats happening (or not happening?) that might be preventing the phone from connecting to the 5000?
-
.. I forgot to mention, I do have the Public IP in the DB under IP Connections>NAT IP Address and for the phone, Nat Address Type set to NAT
-
you need all these ports open for it to work
67-68 UDP
69 UDP
20001 UDP
3998-3999 TCP
6800-6802 TCP
5004-5007 UDP
6004-6261 UDP
6604-7039 UDP
50098-50508 UDP
Plus put the public IP under IP connections (P6000)
-
edtomfish,
Alright, let's start at the beginning and see where things are at.
Under System > Devices and Feature Codes > IP Connections: Set the Base IP connections Public IP Address
Under System > Devices and Feature Codes > IP Connections: Set the PEC IP connections Public IP Address <-- This requires a second public IP Address or audio won't work if you don't have a PEC ignore this step.
Since you say that you have a full 1:1 NAT then opening ports is not the issue, but some firewalls still do block information if not setup properly.
To get a phone to come up it only requires connecting to the Base IP Address. The PEC is only going to effect audio not the phone functionality.
So, we know when a phone tries to connect it will boot up and look at the Public IP pointed to the Base NIC. It will look for TFTP [UDP: 69 or 20001] to see if it needs a new software load. It will then look to make a MiNet [TCP: 6800-6802] data connection to the Base NIC. At this point the phone should come up and start working as MiNet is for Call Control, but without SAC [TCP:3998-3999] HTML and DSS/BLF functions won't work so you should see those coming from the MiVO-250.
It sounds like your ports 6800-6802 are not getting through in both directions so I would look at that first.
Once it is up then you will need to worry about your audio getting through.
Base NIC: UDP: 6004-6261
PEC NIC: UDP: 6604-7039
You will need two different public IP Addresses if you have a PEC there is no way around this!!!
I know that Tech1302 has a few more ports on their listing, but some of those are for different style phones.
5004-5007 = Inter-Tel IP Endpoints
50098 - 50508 = Mitel IP Endpoints going out which usually does not have to be opened up unless the firewall is really locked down.
Also as you know you will need the phone to be setup as NAT; which you already stated.
Hope that helps.
Thanks,
TE
-
Thank you for the reply. I'm going to double check everything you posted but I think I've narrowed this down but I'm confused as to why/how to resolve.
I'm watching the traffic at the firewall. Looks like the phone is making an initial request to TCP port 20001 and then its on to port TCP 6801 over and over again. The firewall is letting it thru and passing to the Mitel so I did a port scan on the server and that port isn't open (6800 is however).
-
So, we know when a phone tries to connect it will boot up and look at the Public IP pointed to the Base NIC. It will look for TFTP [UDP: 69 or 20001] to see if it needs a new software load. It will then look to make a MiNet [TCP: 6800-6802] data connection to the Base NIC. At this point the phone should come up and start working as MiNet is for Call Control, but without SAC [TCP:3998-3999] HTML and DSS/BLF functions won't work so you should see those coming from the MiVO-250.
It sounds like your ports 6800-6802 are not getting through in both directions so I would look at that first.
TE
Double checked everything...
So you're right, this is where we are right now. 6801, 6802 are not showing open on the Mitel box and the phone is trying to reach it on 6801. What would cause this?
-
Every single one of these is open on the firewall, however, not all seem to be open on the mitel box and I believe 6801 and 6802 are the reason why the phone is hanging up.
you need all these ports open for it to work
67-68 UDP
69 UDP
20001 UDP
3998-3999 TCP
6800-6802 TCP
5004-5007 UDP
6004-6261 UDP
6604-7039 UDP
50098-50508 UDP
Plus put the public IP under IP connections (P6000)
-
you can see the open ports from the web firewall section.
-
Sure enough. I didn't know this existed. It doesn't show 6801 as being open. I attempted to add a rule here to allow it, but that did seem to do anything. I'm not seeing much documentation on this anywhere either. Is this builtin firewall accessible another way?
you can see the open ports from the web firewall section.
-
edtomfish,
Unfortunately I do not have a MiVO-250 to test with so I can't answer as to what ports you should see open and which you shouldn't. If memory serves me correctly the system should have responded, but the phone should have sent the request on port 6800.
Sorry,
TE
-
edtomfish,
I don't know if you are still working on this, but it just occurred to me that the local phones are up and working fine without ports 6801-6802 being open on the system so this most likely is not the issue. Have you tried to perform a Wireshark capture from a phone on site to the MiVO-250 and see the ports that are used and in what order they occur in. This should help you figure out where the communication failure is.
I am currently working on our 3300 side and will be working on them throughout the Summer with no access to a MiVO-250, but if you can get the Wireshark captures from both sides I can help you translate what is going on.
Thanks,
TE
-
I just did this actually and was coming back to follow up!
So the packets are making it in to the LAN. Looking at the capture, the local phones are communicating via 6800 which is OPEN. The external phones are communicating (trying to) on 6801 and that port is closed. I see the packets come in and RST ACK.
-
I don't see any local traffic attempting 6801, or any external's trying to use 6800.
-
edtomfish,
I know you have probably already tried this, but have you taken the phone into the LAN set its extension for Native and made sure it comes up without any issues?
Does the phone system have the proper gateway and can it ping something outside the network? You can do this through the command console of the MiVO-250.
It seems like you are right on the cusp of getting this to work, but just missing something not so obvious at the moment. Are there any other Teleworker phones working? Can you try your phone to another MiVO-250 that you know has working Teleworker phones?
I don't think your problem is with port 6801 not being open on the system. I will have some time tomorrow night to work on my system at home and see if I can figure anything out.
Thanks,
TE
-
I appreciate your thoughts here... sometimes its just nice to know someone is listening, lol.
I cant get any phone to working outside the office. Tried 3 different phones at 3 different locations.
The phone works on the LAN perfectly (first thing tried)
Gateway is good. It can communicate outside fine. Proof of this is that it can TFTP (UDP port 20001) with the phones just fine.
The only difference I'm seeing is that all the internal phones are using port 6800 and anytime outside they are wanting to use 6801 and those packets aren't being heard by the server.
The problem might NOT be 6801 not being open on the system, but if thats the case the problem is the phones using 6801 and not 6800.
The only thing I have NOT done is tried this phone on another 250 which I'm trying to work out...mainly because I want to see what that traffic looks like compared to what I'm seeing now.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
..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.
-
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.
-
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
-
As backwards as it sounds it makes sense. I'm excited to try this tomorrow.
-
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?
-
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
-
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.
-
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