cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1638
Views
10
Helpful
15
Replies

Slow down Jabber connection on after a PC resume? Or ability to connect Jabber to VCS-E behind another insitutions firewall

Chris Swinney
Level 5
Level 5

I have re-titled this thread as the conversation moved on from the inital idea of stopping Jabber to access to the Home VCS-E when on site, to actually need to access a VCS-E when at a remote site.

Hi all,

VSC-C and E : x7.2.2

Jabber Video: 4.6

This is an odd question as we have an odd problem. We have a sample deployment as shown in the diagram below:

Basic Single site operation 3.png

This all works fine - assuming the roaming users Jabber client registers to the correct VCS. The problem comes when the remote users puts their laptop to sleep, brings it into work, connects it to the dock and wakes the machine up. It seem that the Jabber tries to connect before the Ethernet connection is fully active, therefore the connection to the local VCS-C for provisioning info fails. However, I believe the Ethernet connection then comes up as Jabber then attempts to contact the VCS-E (as it would do when offsite). This mean that the provisioning info fed to Jabber is that for an external connection so Jabber then registers quite happily to the VCS-E :

Basic Single site operation 2.png

The problem comes then when attempting to make or receive a call - the Jabber client connects but the user doesn't receive any audio and video. I suspect that the problem lies in the institution firewall as the call is essentially routed to the client via the VCS-E and so the firewall is blocking the UDP traffic to the client.

If there was a way to slow down the Jabber client after a system "wake" (all is Ok from a boot), then this would resolve this problem.

However, after thinking about this - maybe the best way would be to block outbound access to the VCS-E on port 5060 and 5061 at the firewall?

Comments please?

Cheers Chris

15 Replies 15

Paulo Souza
VIP Alumni
VIP Alumni

Hi Cris,

Are you saying that your internal jabber users are able to register to VCSe?   That is bad.

That is not common, because when you implementing VCSe + VCSc, the best practice is to allow only VCS Control to reach VCS Expresway crossing the firewall, all other devices should reach VCSc alone (or neighbors), not VCSe directly.

If I tried to suggest any of our customers to allow their internal devices to access VCSe directly, the security team would probably deny me to do that, because the purpose of VCSe is to isolate the networks to improve security.

In my opinion, the best option you have is deny your internal devices to reach VCS Expressway.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Yeah - it's a bit of a legacy hang over - we are just tightening things up now.

However, I think this as not that uncommon. We are in education (University) and all users pretty much have unrestricted outbound access. This means that they can connect to pretty much any device external to the firewall and that outbound established connections will allow return traffic - so a registration using TCP to the VCS-E will be allowed unless explicitly denied - which it hasn't been. However the UDP traffic from the VCS-E to the client WILL be blocked as it is unestablished and connectionless. So the user can connect yet will not receive audio/video.

Hence the last sentence in my post above - I initially started the thread out with the wrong thinking, but changed by the time I had reach the end of the post! I will set up and explicit block (apart from manament traffic) to the VCS-E from all internal devices.

Cheers

Chris

I'm having a similar problem, and, as it happens, I'm also in a university environment

We tried adding a policy on the firewall to stop JabberVideo users from registering with the VCS-E from inside, which "kinda" works, but once they go Wi-Fi (Eduroam) the routing changes and once again they can register with the VCS-E when they are physically on campus.

It's not a great problem - at least not at this stage, as it's limited to the JabberVideo users in a very limited scenario, but.....

/jens

Please rate replies and mark question(s) as "answered" if applicable.

Thanks for the confirmation Jens - I hadn't even considered Eduroam! I'll talk to the networks teams tomorrow to see what their implementation of Eduroam is, but I think in our case Eduroam and Internal network traffic is routed through the same firewall. However, this also answers another question of connectivity I had seen on a separate institutions campus WRT to Eduroam. We are in a similar position in that Jabber is not extensively used, but I am hoping it will increase. Problem is, Lync is the flavour of the month.......

Hey Jens,

I woke up this morning in a bit of a sweat thinking that Eduroam is going to cause us some issues. Of course, the example topology shown above is not the whole story. We actually employ single VCS-Es acting as traversal servers to MULTIPLE institutions - this works as a National network for educational establishments and public bodies. Indeed the intended direction is to cluster these VCS-Es to provide resilience, such that:

Now the tricky part. Each of these organisation potentially has Eduroam. It means that a user who's home organisation is 'A', could travel to organisation H and still have Internet access through a wireless single sign on. Of course, we would block inbound access to the VCS-C at Org A, so the travelling user should be allow outbound access at H to register to VCS-E 1 (but potentially, the could register to ANY of the VCS-Es). Org H must allow inbound UDP streams from the VCS-Es to the travelling users, but would still want to block its home users from registering to a VCS-E so that they only register to the local VCS-C.

Nice.

I guess we should be able to define inbound filters based on the source ports of SIP UDP traffic from the VCS-Es, but I'm not sure if these can be applied to the different categories of Eduroam user - those who are on Eduroam at their home location and those who are travelling.

It is also possible the users will connect via VPN to their home network, but such overhead on wireless network might be a bad thing if user then connect to their home VCS-C (although we do have users do this at the moment with minimal degradation - but of course then thing think bandwidth control in the provisioning template will assume on site access and set the connection at full speed, where as I might want to limit this.

What a doozy! I'm off to speak with the wireless and Networks team......

I'm right in thinking the the default UDP SIP outbound port for Media are defined in the Traversal Subzone (50000-54999)? However, there are also TCP outbound port set up in the SIP configuration (25000-29999), although we don't utilise TCP connection for media to the client.

Well, good news form the networks team is that they should be able to accommodate us. Eduroam is set up with multiple VLAN and so different rule sets can be applied to different users (whether they be a home user or travelling user).

Whilst they are willing to enable an ACL to open UDP ports from 50000-54999 allow media INBOUND to roaming users as a test, I doubt this would be acceptable going forward and I can't see all universities (potentially across the world) wanting to do this. I think that the default setup of Jabber is to use TLS, and as such I 'think' that during the call set up when he media ports would be negotiated, this traffic would be encrypted and so any inspection by a firewall to enable dynamic ports to be opened would be fruitless.

As much as I hate to say it - maybe the only alternative would be for users to tunnel to thier home site using a VPN!!!!

Hi Cris,

Looking to your topology, now I have better view of your issue.

Well, I guess I have an idea, but I am not sure if it works well, once I have never tested such thing. I would suggest you this:

Maybe you can use an unique FQDN to point the Internal Server (address of VCS Control) configured in the Jabber clients. You can stablish a common FQDN to be used for all organizations, A, B, C, D and so on. Then each organazation will have a DNS server configured to resove this FQDN to its local VCS Control's ip address. For example, lets say you create the FQDN videoconf.domain.com. Then, in organization A, the DNS server would resove that FQDN to the ip address of its VCS Control. In organization B, the DNS server would resolve that FQDN pointing to the ip address of its VCS Control, and so on.

Of course, in order to have this setup working, you should have one single provisioning data base shared along all the VCSs in the topology, I guess you have it, right? You should also have a dial plan that allows all the clients along the topology to dial each other.

I am not sure if it works well, but it is supposed to work, I guess. But I have never tested it personally.

What do you think?

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Cris / Jens,

With regards the local clients registering to VCSe when Windows resume, I think that the best option would be blocking internal users to register to VCSe. If you cannot do that in the network devices, I would suggest you to block users by using the internal firewall of VCSe. You can block all the internal networks to access VCSe, except the IP address of VCS Control and external addresses. Of course, you just jave to block SIP ports, so that administrators can still have access to manage VCS.

Does it help?

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Hi Paulo,

Well yes we have the topology. A single TMS instance feeds all users are although currently grouped and arranged in a potential cluster --> vcs-e --> vcs-c fashion so the provisioning information is is assigned in the fashion.

However, this is one one the first comments of yours I have read that I don't really agree with ;). There are just too many variables - too many network teams and institutional topologies. We have over 50 organisations and not all would follow this methodology. Still, makes for some fun discussions!

Each organisation is autonomous, and dns servers are not set up for such a strategy.

Hi Cris,

It seems you have a really uncommon environment. =)

Well, this is the best I can suggest for now, any other suggestion would demand a detailed analysis. Anyhow, either following my suggestion or any other, I think that your problem will demand a great effort, once you have a complex deployment. It is not gonna be a easy task.  =/

However, this is one one the first comments of yours I have read that I don't really agree with ;). There are just too many variables - too many network teams and institutional topologies. We have over 50 organisations and not all would follow this methodology. Still, makes for some fun discussions!

Each organisation is autonomous, and dns servers are not set up for such a strategy.

PS: I posted a superficial suggestion because I have a supercificial view of your environment. Everything I see is the topology you posted. Sorry.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Don't be sorry. You have been on the money most of the time :)

It has been difficult to post the entire topology as it is too complex. So I have to approach it in chunks. Of course, it's not easy to get the full picture.

You are right though in thinking that this is not a common environment!!!! Cisco and in fact most manufacturers view installations on a per organisation basis. We have a national infrastructure, the beginnings of which date back to to the late '90s. The problems we face are trying to bend this to fit modern technology. We're getting there, but there will always be obstacles.

Yep. In the first instance I have ask our local networks team to simply block 5060 UDP and 5061 TCP for all home organisation users. Traveling users will be allowed to register to an external VCS-e and a UDP filter will allow traffic in bound for them. I had forgotten that x7.2.2 had a ACL built in as although we have it in our test zone, the live environment pretty much has x7.1. I would still prefer this to be implemented at the institution level

I think I can tighten things up a lot more. I think the 5000 default media ports would be way to many for the expected number of traveling users (although these on the VCS-e have to cope with all potential outgoing calls, but agin the vast majority of these are passed to an internal VSC-c over a traversal zone). Further, I need to check the default media ports for jabber (which of course can be changed in the provisioning template). If i tie down a limited port range from the VSC-e to jabber, they will be a lot happier with this - but not ecstatic!

Hi Chris,

You certainly have a much larger deployment to manage than me - so I guess the headaches are propotionally bigger too.

As for Eduroam, here it is now also being rolled out to Health, so it is available in more and more hospitals around the place, making it even harder to lock down.

We certainly don't want to go down the route of forcing users to VPN in when outside campus as this will introduce yet another layer of potential support issues, so I guess it becomes a compromise between usability and security, and being a university, well, ease of access and usability are what it's all about.

We also have a number of "free" Jabber users (jabber.com) so we need to allow for this as well - which throws another spanner in the works - oh, and then there's EVO which also needs to work, and Skype...

Having a small deployment consisting of two VCS-C and one VCS-E makes it at least realtively easy for us to monitor usage and to identify and stop any suspect behavour not picked up by CPL etc - in your case that might not be so simple...

Must say I find your posts absolutely fascinating makes me appreciate how easy my life is here.

/jens

Please rate replies and mark question(s) as "answered" if applicable.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: