Hello,
We've been having a lot of trouble with getting various ShoreTel equipment to work. We currently have it deployed at several of our locations, but each time we want to add something new to the network, we often hit a snag.
Our latest instance has occurred in our Milan office where we are attempting to install a new DVS server associated with our VoIP deployment. We can't get this server to communicate with any other of our offices, including the HQ site via ShoreTel proprietary ports 5440 and 5446. ShoreTel insists our network is preventing it.
Our VoIP traffic traverses IPSEC tunnels along with other inter-site traffic. We do not filter any ports over these tunnels. Our support company, Cisco, and myself have all confirmed we are not blocking anything on the firewalls, and even packet tracers suggest as such. We see bidirectional traffic between all subnets in question over these tunnels and packet captures have shown some nominal TCP resets. The only specific flag I see in a firewall log message is the "TCP Reset-I" flag, which research suggests means that the connection is reset from the inside host.
I can see connections on other ports between the ShoreTel servers on other ports. Similarly, I can telnet to it via various other ports, but not from ports 5440 or 5446. I can, however, telnet to the other servers via port 5440, and I can see the successful connections on the firewall. However, when I attempt to telnet to the server in question via port 5440, it fails so swiftly that I don't see anything as far as a failed connection. As noted before, I do see occasional TCP Reset-I messages in the logs.
I think we pretty much eliminated the firewall as our culprit, and pretty much everyone involved in this conundrum seems to agree. That leaves only the connected switch (which is connected to both, the server and the Firewall inside interface) and the cable as our guilty parties. The cable seems to also be eliminated as we see other traffic traverse the interface toward the ShoreTel DVS with no errors, collisions, or drops. This interface also has no history of bouncing.
So now we seem to be down to the server, the ShoreTel implementation on the server, and the switch as our potential cause. Although my understanding of switches as that of layer-2 (and sometimes, layer-3) devices, TCP and UDP are typically layer-4 entities. Therefore, I have never seen a switch ever block a layer-4 port at any time at any time in my career (or anyone else mention it to me). However, since the first couple of times we put the first DVS on the network, which completely caused havoc to every one of our sites with a ShoreTel presence (our other sites were unaffected), I agreed to follow this thing through as if that was definitely our problem. Besides, that crash seems to have had a minor effect on the connected switch in the form of "re-transmits" that we noticed in our packet captures in much the same manner you see other switches incur damage due to outages caused by Spanning Tree.
For the sake of argument, I attempted to RMA this switch, but it was rejected by Cisco for insufficient evidence (They were also involved in the troubleshooting of this issue through a good portion of it). Since we could not, I continued troubleshooting as is. I did so by attempting to telnet to PCs with Windows firewall disabled from the switch in Milan and from PCs with the Windows FW disabled at other locations to Milan. My findings were consistent throughout the entire process: I could telnet to any device connected to any switch via standard TCP ports, but could not telnet to any device (except for the ShoreTel servers that are confirmed to be working) via port 5440. Some research seemed to suggest that this is because 5440 and 5446 are ShoreTel proprietary ports and telnetting to them can be accomplished only if those ports are open for that device, but the device is actually listening on them. If true, that would seem to explain why I could not telnet to my PC using them. This also suggests the problem may not actually be on the switch after all, but with the server somehow not being configured to listen on those ports.
So, taking everything under consideration, I have three questions:
1) Does this seem correct? Should I be able to telnet on those ports no matter what (provided they have been opened on the Windows and network firewalls) or do the devices need to actually be listening on them?
2) Can the switch actually be at fault and be blocking the ShoreTel ports? Could there be an IOS bug causing this? If so, is there a remedy?
3) If the server does need to listen on these ports, how does one configure them to do so?
