Force Jabber to use expressway and not vpn

[jherlitzke]

Hello,

We have expressway successfully up and running.  Jabber clients connect to it and work great.  However once you connect your anyconnect client, jabber will reconnect to the server through the vpn tunnel.

Am I able to update the jabber-config file to force jabber to always use expressway and not the anyconnect tunnel?  Or any other way to accomplish this?  I just initially assumed jabber-config file.

Thanks, 

[Jaime Valencia]

You can certainly use the excluded services option from Jabber to tell it to not use CUCM or CUP, but you'd still send all the traffic via that VPN tunnel. If that's what you want to avoid, you'd need to look at this with the VPN guys to find if there's a way to exclude Jabber from using the tunnel.

[jherlitzke]

Thanks for the reply Jaime,

I was reading up more on the process that Jabber takes to connect.  Seems like it would be a DNS thing to update.  Right?  So when Jabber opens up it looks for the domain.  If internal it see's the Server's from the internal DNS Servers.  If outside of network then it see's DNS from the public DNS servers and connects through Expressway.  Now jabber continues to monitor so once vpn is connected it see's internal DNS servers and reconnects automatically.  Obviously we want to use internal DNS servers when on VPN so we can access network resources for everything else.

Now I can't mess with the internal DNS servers....  If I block the subnets for the voice servers on the vpn, then it would just fail.

hmmmm, trying to think through this and decide how I would pull this off...

[Jonathan Schulenberg]

You’re on the right track: the internal DNS servers would need to resolve only _collab-edge and not _cisco-uds for a VPN client. Some DNS servers have a View feature that allows different resolution behavior based on the source IP address of the query. Excluding the CUCM/IM&P/CUC server sinners from the VPN include list wouldn’t do the trick.

Also, a reminder that MRA is not feature complete vs. internal/direct - including VPN - registration. In my opinion, if users are on VPN, then it’s preferable that they don’t use MRA.

[jherlitzke]

Thank you for your reply.  I do like this option.  If I am reading this correctly.  When users are on our internal network, all will work as normal.  If I was able to determine how to setup the view feature, I wouldn't block the IP network of the VPN but just the CUCM entries forcing them to look at a public DNS server?  If we have two internal DNS servers, as far as vpn dns servers assignments these would be the top two and I would have to add a public DNS server as a 3rd option then so it would look there and then connect through expressway?

I understand that ideally it would be great to have users connect through the vpn, however we are currently experiencing some major microbursts on our WAN router where VPN users traverse through.  I don't believe voice is causing the issue, but sure is being affected by it.  All my reports from users point to using vpn outside of the office for jabber.  So this is my step to try to resolve the voice quality issues while we work on the micro burst's. 

[Ammar Saood]

according to me, the easier way would be to use only collab-edge SRV record in your DNS server. this way jabber will always connect via Expressway.
Remove SRV records for _cuplogin and _cucm-uds. this will force jabber to always use _collab-Edge record.

2ndly you can also add only external DNS server in your TCPIP setting. which will force your machine to query external DNS only.

HTH
AMMAR SAOOD

plz mark answered and rate if helpful.

[jherlitzke]

Hi Ammar, 

Thank you for your reply as well.  With your suggestion correct me if I am understanding this wrong.  However your suggestion would make them connect through expressway even when internally on the network?  I wouldn't want them to essentially leave the network to come back in to make internal calls or even external calls over our SIP.

Or was I misinterpreting your recommendation.  Which very well could be so I apologize if I am. 

[Alok Jaiswal · Accepted solution]

You can probably use the method defined in this document. When i was in TAC i think we helped one of the customer to achieve this. But this document use Cisco ASA as the background infra. But i am sure similar thing can be done on other Firewalls.

Check the "Firewall Configuration" section in below document. Basically what you would be doing is when people on VPN they should not be able to SRV query for Cisco-UDS.

https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Borderless_Networks/Unified_Access/BYOD_Design_Guide/BYOD_CollabEdge.html

Regards,

Alok

[vijendra Saravanamuthu]

this ASA doc is great. it does block the internal SRVs being resolved by vpn clients.  however the vpn jabber clients still send queries to internal DNS to reslove _collab-edge._tls which doesn't exist internally so the client fails to find MRA via expressway.  

our idea is to have jabber client connected via expressway regardless vpn is connected or not.

any suggestion is appreciated.

thanks. Vijay

update:: after fully reading the doc , i realized that corporate DNS must also have the A records for exp E along with SRV records for _collab-edge._tls.  i believe this is normally not required unless there is a requirement to enable jabber client to stay connected via expressway regardless of VPN.  thanks.

[Roger Kallberg]

AFAIK you would need have another record in combination with the SRV as this record need to point to something.

[Michael Stark]

Using the method listed by TAC does work and you block the internal SRV records. Therefore forcing it to find the external Collab edge SRV. Note: when signing in from the start (first sign in) it does slow down that initial login time to around 30 seconds. Once you’ve signed in the next time it is fast. Just appears initial discovery on your first sign in can be slowed down as it attempts to find the internal records.

[Sandesh Pawar]

Hi Guys, We are using Zscaler for the VPN connectivity and have bypassed SRV records "_cisco-uds._tcp.<domain>" & "_collab-edge._tls.domain." we can see that jabber connects via expressway.

However we see every time the laptop comes out of sleep/Hibernation the Jabber client tries to reconnect to the CUCM already discovered previously. These are creating log of logs in the Zscaler. 

Any thoughts on a scenario where the jabber is connected via expressway however looses network connectivity would the Jabber retry the discovered UC Apps via VPN & does that mean we should also bypass the UCApps and not just the SRV.

[Roger Kallberg]

I would say that since Jabber caches the result of the service discovery it would likely be advisable to bypass/exclude all the FQDNs for any UC system that the client connects with after the service discovery has completed.

[alfemmig]

Hello Sandesh

i am trying to do the same thing with Zscaler ZPA and I keep having issues connecting to the sever. I have created an application segment to bypass the two records you mentioned as well as the _cuplogin.domain.com. However we are getting can<t connect toi server reply. When we look at the wireshark traces we are not seeing a query for the _cuplogin.domain.com however the two FQDN server names that are associated with the service record are queried (we have also added them to the bypass segment) the response comes back as no such name but yet we can<t connect ti the server.

Can you share some more info on how you have set this up.

Thanks

[Roger Kallberg]

Not directly an answer to your question, but  _cuplogin service discovery only applies to old versions of Jabber. If you’re not using pre 9.6 version of Jabber you do not need to have this SRV record.