VCS Starter Pack - Issue with TCP ports and Jabber

[Paulo Souza]

Hi Folks,

I have a basic and very small deployment involving VCS Expressway Starter Pack and some Jabber clients. VCS Expressway is using version 7.2.2 and it is configured with 2 interfaces, one connected to the external DMZ and other connected to the internal DMZ. The topology is something like this:

Jabber >> [Firewall] >> (LAN2) VCSe-SP (LAN1) >> [Firewall/NAT] >> Internet

The issue I am facing is related to the Jabber client trying to register to VCS via LAN2. According to the documentation, only the following ports would be required for Jabber for Telepresence:

• 5060
• 5061
• 50000 - 52399

However, when Jabber clients try to Register, VCS sends the SIP Notify message using another TCP source port, a port in the range 25000. This is what happenes exactly:

- Jabber sends SUBSCRIBE message (Jabber source port: 61390 / VCS Destination port: 5061)

- VCS challenges for authentication (VCS source port: 5061 / Jabber destination port: 61390)

- Jabber resends SUBSCRIBE message with authentication (Jabber source port: 61390 / VCS Destination port: 61390)

- VCS sends 200 Ok (VCS source port: 5061 / Jabber destination port: 61390)

- VCS then sends SIP Notify message (VCS source port: 25066 / Jabber destination port: 61390)

- Timeout. Firewall blocks the connections since the source port used by VCS is wrong. It should be 5061 instead of 25066 (VCS's SIP TCP outound range)

Checking the network log in VCS I find the "TCP connection failed" error message:

If I use tcpdump to check the traffic in the LAN2 of the VCS, I do confirm that the 25066 port is being used as source port indeed:

Well, I did some tests in another environments which have Full VCS Expressway (with dual NIC) and Jabber and I did confirm that, in all of them, when Jabber is attempting to register, VCS uses only 5060 or 5061 ports as source port for signaling, the range from 25000 is never used.

Has anybody here seen this issue before?

Thanks in advance.

Regards

Paulo Souza

[Martin Koch]

Hi Paulo!

I assume the 172.20.16.48 client is not behind NAT right?
Which port are you anyhow more surprised of, the 25066 or the 61390?

The VCS-E is not the ideal comparison, at least if your client was behind NAT,
you should compare it to a VCS-C deployment and a direct connectivity.
Is the call routing in your setup set to optimal or always? That might have an impact as well.

Do you have a sip trace on (preferred) the JabberClient (using the debug levels),
or from the VCS-E (or both)?

By that I could explain you why it is happening.

Anyhow it is the proper behavior, check out the firewall guides (checked in x7.2.2 and x8.1)
(I wanted to attach the graphics, but with the new editor it did not work, ..........)

page 25:
http://www.cisco.com/c/en/us/support/unified-communications/telepresence-video-communication-server-vcs/products-installation-and-configuration-guides-list.html
sip signaling source for tls: 25000-29999
so thats fine!

the 50000-52399 range is only for udp media on the vcs, you want to check anyhow
in your vcs used ports list if this is still true as it got extended with x7 and x8!

I did not find anything about the used tcp ephericial ports for jabber video, I would simply expect 1024>65535

So from here for now I say, it looks fine and open up more ports in the firewall.

[Paulo Souza]

Hi Martin, thanks for your reply.

I am surprised about the port 25066 that VCS starts using as source port when sending the SIP NOTIFY message. VCS is supposed to keep using the same port, 5061, as source port, as far as I understand, instead of using another port.

I am aware that 25000-29999 is a range of SIP TCP/TLS source ports, however, those ports are used for SIP outbound, according to documentation, that means, when VCS starts sending the INVITE to the remote side. But in my case, VCS is receiving the call setup.

In addition, my client is not behind a NAT and the 61390 port is the real source port used by Jabber when conecting to VCS.

To make sure that I am not missing anything, I have checked another deployments, including  Jabber clients registered to VCS Control and Jabber clients (NOT behind NAT) registered to VCS Expressway. In both cases, the 25000-29999 range is never used when VCS Control or Expressway receives the cal setup, but only when VCS starts sending the call setup.

Therefore, I really think that there is something strange going on here. I will check the call routed mode, just in case. I will also try to use TCP and UDP instead of TLS.

I appreciate your help. Thanks.

Regards

Paulo Souza

[Martin Koch]

Do you have a chance to have no firewall in between the vcs and the client?

(like place the endpoint in the same subnet as the vcs). Just that you can check

how it behaves.

I would also be interested in how it behaves if you would have NAT in

between the client and the VCS.

How is the call routing setting, optimal or always, does it change something if you change that?

It would be interesting to see a pcap file and a debug output of the vcs.

And if it fails the same way on tcp, thats nicer to look at.

The NOTIFY should be the same Dialog but a different transaction.

If I read it right in RFC5923 the TLS connection shall be reused, but it

could also be a new one, as its a new transaction outbound to the client

the behavior if the vcs should be ok.

The dual interface option is bit special, provising (especially with the starter pack) as well

So not sure which impact both have in comparison to a single interfaced vcs-e.

[Paulo Souza]

Hi Martin,

Thank you very much for your tips.

Unfortunately, I cannot have no firewall between VCS and Jabber. I also tried to totaly disable TLS, but with TCP the issue remains the same.

I have asked firewall administrator to open any any involving Jabber and VCS, and I have also disabled all security application on the desktop where Jabber is running, however the issue remains exactly the same.

I just upgraded VCS to the version 8.1 and Jabber to the versin 4.8 (both latest) and the issue remains the same.

One more time, I have asked firewall administrator to turn off any SIP/ALG inspection mechanism on the firewall and they made sure that the firewall is not working with SIP signalling.

The only thing I have not tried is to run wireshark on the windows for further investigate, however, I am working in many projects at the same time, so I had to go ahead and open TAC case. Lets see what TAC suggests.

Regards

Paulo Souza

[Martin Koch]

You saw what I wrote, right?

As you have a firewall anyhow, can you enable NAT 

  Internal network > VCS-E-IP2

That would force the VCS-E not to see the real internal IP address.

That at least should make the VCS aware not to send something directly from some random port.

I tried it with a single interface VCS-E and a public IP device. I did not see

that it happened there. The only time I saw sip messages from highports

was when it tried to reach an old registration which was still on the VCS but

not existant by the device anymore.

As I said the starter pack is strange anyhow. It does not have the concept of

internal and external ip for provisioning. So to register you would need

need a split DNS or point all to the external IP address which is NATed.

Thats an other option that there is something not 100% correct deployed

and what you see is more a symptom rather a cause.