Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1327
Views
0
Helpful
4
Replies

Jabber registered to Traversal Zone, call out to DNS

Paul Woelfel
Level 4
Level 4

‎12-02-2012 03:26 AM - last edited on ‎03-25-2019 09:06 PM by Community Manager

Hi,

I've got a question regarding Jabber Clients registered to the Traversal Zone of the VCS-C via VCS-E. I've set all challenging settings acording the VCS Device authentication guide 7.2 and the jabbers are able to register.

BTW: Proxying the authentication also works with Default Zone and Default Subzone set to check credentials. In the authentication guide and this discussion it is recomended to set it to "do not check credentials". I just created a search rule for the domain and pointed it to the traversal zone and set the proxy mode to "Proxy to known only".

If I try to call a local endpoint it works fine and the call is challenged and authenticated. If I try to call an external participant I'm not able to make a call. According to the guide, it should be possible, to route the call to VCS-C to check the credentials and then route it back to the VCS-E. If I check my search rules, the call is routed from Expressway to Control, but then the search rule (any alias, any source, no authentication required) does not match. So client registered to the Traversal Zone is not able to call an external participant.

If I check the search history, I see the search is routed to the VCS Control:

  • Search (359)
    • State: Completed
    • Found: False
    • Reason: Not Found
    • Info: Policy Response
    • Type: SIP (INVITE)
    • CallSerial Number: 74aaecc0-3c6d-11e2-bd67-0010f31d174a
    • Tag: 74aaee6e-3c6d-11e2-a8b4-0010f31d174a
    • Source (1)
      • Authenticated: False
      • Aliases (1)
      • Zone (1)
        • Name: DefaultZone
        • Type: Default
      • Path (1)
        • Hop (1)
          • Address: 10.0.0.9:53321
    • Destination (1)
    • StartTime: 2012-12-02 11:45:58
    • Duration: 0.09
    • SubSearch (1)
      • Type: Transforms
      • Action: Not Transformed
      • ResultAlias (1)
      • SubSearch (1)
        • Type: Admin Policy
        • Action: Proxy
        • ResultAlias (1)
        • SubSearch (1)
          • Type: FindMe
          • Action: Proxy
          • ResultAlias (1)
          • SubSearch (1)
            • Type: Search Rules
            • SearchRule (1)
              • Name: local Any Alias
              • Zone (1)
                • Name: LocalZone
                • Type: Local
                • Protocol: SIP
                • Found: False
                • Reason: Not Found
                • StartTime: 2012-12-02 11:45:58
                • Duration: 0
                • Gatekeeper (1)
              • Zone (2)
                • Name: LocalZone
                • Type: Local
                • Protocol: H323
                • Found: False
                • Reason: Not Found
                • StartTime: 2012-12-02 11:45:58
                • Duration: 0
                • Gatekeeper (1)
            • SearchRule (2)
              • Name: send unauthenticated calls to Control
              • Zone (1)
                • Name: TraverselZone
                • Type: TraversalServer
                • Protocol: SIP
                • Found: False
                • Reason: Not Found
                • StartTime: 2012-12-02 11:45:58
                • Duration: 0.07
                • Gatekeeper (1)
              • Zone (2)
                • Name: TraverselZone
                • Type: TraversalServer
                • Protocol: H323
                • Found: False
                • Reason: Not registered - Destination not found
                • StartTime: 2012-12-02 11:45:58
                • Duration: 0.01
                • Gatekeeper (1)

I created a Search Rule on the VCS-Control:

Screen Shot 2012-12-02 at 12.11.59.png

So this rule should match in any case (if the previous didn't stop searching), but it does not:

  • Search (73)
    • State: Completed
    • Found: False
    • Reason: Not Found
    • Info: Policy Response
    • Type: SIP (INVITE)
    • CallSerial Number: 76bf6478-3c6d-11e2-979e-0010f31d17be
    • Tag: 76bbde84-3c6d-11e2-b25c-0010f31d174a
    • Source (1)
      • Authenticated: True
      • Aliases (1)
      • Zone (1)
        • Name: TravesalZone
        • Type: TraversalClient
      • Path (1)
        • Hop (1)
          • Address: Public IP:7001
        • Hop (2)
          • Address: 10.0.0.9:53321
    • Destination (1)
    • StartTime: 2012-12-02 11:46:01
    • Duration: 0.03
    • SubSearch (1)
      • Type: Transforms
      • Action: Not Transformed
      • ResultAlias (1)
      • SubSearch (1)
        • Type: Admin Policy
        • Action: Proxy
        • ResultAlias (1)
        • SubSearch (1)
          • Type: FindMe
          • Action: Proxy
          • ResultAlias (1)
          • SubSearch (1)
            • Type: Search Rules
            • SearchRule (1)
              • Name: Local zone - keep uri/number
              • Zone (1)
                • Name: LocalZone
                • Type: Local
                • Protocol: SIP
                • Found: False
                • Reason: Not Found
                • StartTime: 2012-12-02 11:46:01
                • Duration: 0
                • Gatekeeper (1)
              • Zone (2)
                • Name: LocalZone
                • Type: Local
                • Protocol: H323
                • Found: False
                • Reason: Not Found
                • StartTime: 2012-12-02 11:46:01
                • Duration: 0
                • Gatekeeper (1)

I also checked the poison mode, but it is set to off. For me it looks like, a search rule pointing to the source of the call is not considered, when making a call.

What am I missing to route the call from external -> VCS-E -> VCS-C -> VCS-E -> DNS ?

Regards, Paul
Labels:
0 Helpful
4 Replies 4

Paul Woelfel
Level 4
Level 4

‎12-02-2012 09:25 PM

Hi,

I found a solution:

I created a second Traversal Client Zone called "TraversalOut" to the same Expressway. As a call is routed to VCSC it uses the first Traversal Client as source zone and a search rule targeting the new TraversalOut zone will forward the call back to the Expressway.

With this setup it is possible the authenticate users registered to traversal zone and make use of findme source rewriting.

Is there any better solution to realize this?

Regards,
Paul

Sent from Cisco Technical Support iPhone App

Regards, Paul
0 Helpful

Bill Ruhnke
Level 1
Level 1
In response to Paul Woelfel

‎12-03-2012 12:14 PM

One way this works is to put a search rule on the VCS-E of ANY ALIAS > EXTERNAL DNS before the rule that passes any alias to the traversal zone.  Logically you would think to check internal, then external, but this fixes the problem of Movi clients from outside, registering to the inside, then calling outside locations.

0 Helpful

Paul Woelfel
Level 4
Level 4
In response to Bill Ruhnke

‎12-04-2012 04:27 AM

Hi Chip,

I had this before, but this is not quite the solution I want. The main issue is, that anyone could use your system to dial an external participant, because the source of the call is not authenticated. To get more security I added some CPL rules, so only special sources are allowed to dial out from the Expressway.

The second issue is that the source address is not rewritten to the FindeMe address, because the Expressway do not know about these addresses.

So the call has to go through the VCS-C to check the credentials and rewrite the source address.

Regards, Paul
0 Helpful

Martin Koch
VIP Alumni
VIP Alumni
In response to Paul Woelfel

‎12-04-2012 05:11 PM

I think looping the traffic through the vcsc is not good as it consumes additional resources and will conflict with the loop detection.

An other option I saw was to use one single local auth account. The provisioning request will be handled by the vcs-c and this tells the jabber video client wich username/password to use. Its not great, as its only one password but at least

its not revealed to your users.

I would see that the vcs-e can properly authenticate the calls. Do you use ntlm or ldap auth?

Talk to your ldap/security/firewall/win-admin guys, maybe you find a secure way for your organization

to let the vcs-e access the auth db, if its ldap or ad.

Please remember to rate helpful responses and identify

0 Helpful
Customers Also Viewed These Support Documents