cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
4215
Views
20
Helpful
10
Replies
Highlighted
Beginner

Force Jabber to use expressway and not vpn

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, 

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

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

View solution in original post

10 REPLIES 10
Highlighted
Hall of Fame Cisco Employee

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.

HTH

java

if this helps, please rate
Highlighted

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...

Highlighted

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.
Highlighted

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. 

Highlighted
Participant

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.
Highlighted

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. 

Highlighted

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

View solution in original post

Highlighted

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.

Highlighted

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

Please rate all useful posts
Highlighted

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.