×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Traversal Call Issue - 403 Forbidden

Answered Question
Feb 18th, 2014
User Badges:

Hi,


We have deployed VCS Control with VCS Expressway for firewall traversal and encountered  issue. On the VCSe call status, it says 403 forbidden

when an external endpoint registered as SIP on the VCSe will initiate a call to an internal endpoint registered as SIP to VCSc.


Here are some of the test scenarios we conducted and results:


1. Internal endpoints SIP registration to VCSc - OK

2. External endpoint SIP registartion to VCSe - OK

3. Internal endpoint  to internal endpoint SIP calls via VCSc - OK

4. External endpoint  to external endpoint SIP calls via VCSe - OK

5. Internal endpoint to external endpoint SIP call via VCSc and VCSe - OK

6. External endpoint to internal endpoint SIP call via VCSc and VCSe - Failed (403 forbidden)



On item 6, that's the only problem we are trying to resolve.


What are needed to check?


Thank you.


Br,



Acevirgil de Ocampo

Correct Answer by Daniel Isham about 3 years 6 months ago

I definitely recommend creating a subzone for Movi, as you can also control bandwidth also. I never register anything to the default subzone on the Expressway and disable registration for security purposes. Movi clients register to their own subzone

nes along with subzones for other specific things.


For security sake, I don't like not checking for credentials on the Expressway, especially if you have a ISDN gateway or perhaps the Control has a route out to the PSTN. Toll fraud is not sweet.


I always have deployed SSO via LDAP vs local authentication. It gets tricky when you can't join the Expressway to the domain but still want to authenticate and check credentials. The trick is you need to create a local user on Expressway, then actually create the same identical username and password in active directory. Then in TMS, push out these credentials using the configuration template for the version / device of MOVI.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Patrick Sparkman Tue, 02/18/2014 - 08:51
User Badges:
  • Purple, 4500 points or more
  • Cisco Designated VIP,

    2017 TelePresence

What are the endpoints?

Can you show us the search history on the VCS that is giving you the error?

Is it SIP all the way though?

Any transforms taking place?

deocampo.acevirgil Tue, 02/18/2014 - 09:19
User Badges:
Hi Patrick,

We are using a TANDBERG 1700 MXP as external endpoint registerd as SIP on VCSe and C40 endpoint registered on VCSc.
Both VCS are running X7.2.2.
All calls were pure SIP. No H323 and interworking involved.

Here are some of the event logs from VCSe:

2014-02-19T00:29:18+08:00 tvcs: Event="Call Rejected" Service="SIP" Src-ip="122.x.x.x" Src-port="5061" Src-alias-type="SIP" Src-alias="sip:[email protected]" Dst-alias-type="SIP" Dst-alias="sip:[email protected]" Call-serial-number="d06b2e4a-98b9-11e3-b991-0010f32d03e4" Tag="d06b2fee-98b9-11e3-a905-0010f32d03e4" Detail="Forbidden" Protocol="TLS" Response-code="403" Level="1" UTCTime="2014-02-18 16:29:18,463"
2014-02-19T00:29:18+08:00 tvcs: Event="Search Completed" Reason="Forbidden" Service="SIP" Src-alias-type="SIP" Src-alias="[email protected]" Dst-alias-type="SIP" Dst-alias="sip:[email protected]" Call-serial-number="d06b2e4a-98b9-11e3-b991-0010f32d03e4" Tag="d06b2fee-98b9-11e3-a905-0010f32d03e4" Detail="found:false, searchtype:INVITE" Level="1" UTCTime="2014-02-18 16:29:18,463"
2014-02-19T00:29:18+08:00 tvcs: Event="Call Attempted" Service="SIP" Src-ip="122.x.x.x" Src-port="5061" Src-alias-type="SIP" Src-alias="sip:[email protected]" Dst-alias-type="SIP" Dst-alias="sip:[email protected]" Call-serial-number="d06b2e4a-98b9-11e3-b991-0010f32d03e4" Tag="d06b2fee-98b9-11e3-a905-0010f32d03e4" Protocol="TLS" Auth="NO" Level="1" UTCTime="2014-02-18 16:29:18,433"
2014-02-19T00:29:18+08:00 tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="[email protected]" Dst-alias-type="SIP" Dst-alias="sip:[email protected]" Call-serial-number="d06b2e4a-98b9-11e3-b991-0010f32d03e4" Tag="d06b2fee-98b9-11e3-a905-0010f32d03e4" Detail="searchtype:INVITE" Level="1" UTCTime="2014-02-18 16:29:18,433"


I configured one transform on the VCSe: Transform destination aliases to URI format


Pattern type: regex

Pattern string: ([^@]*)

Pattern behavior: replace

Replace string: \[email protected]


Thanks,


Acevirgil

Patrick Sparkman Tue, 02/18/2014 - 09:22
User Badges:
  • Purple, 4500 points or more
  • Cisco Designated VIP,

    2017 TelePresence

Thanks.


On the VCS that shows the error, goto Status > Search History, and find a failed search and paste that.  From there we can see what is being applied and done to the call.

deocampo.acevirgil Tue, 02/18/2014 - 09:40
User Badges:

Hi Patrick,


here's the search history for the call:


Search (11)

State: Completed

Found: False

Reason: Forbidden

Type: SIP (INVITE)

CallSerial Number: f91c9c16-98be-11e3-a8c1-0010f32d03e4

Tag: f91c9dc4-98be-11e3-9950-0010f32d03e4

Source (1)

Authenticated: False

Aliases (1)

Alias (1)

Type: Url

Origin: Unknown

Value: [email protected]

Zone (1)

Name: DefaultSubZone

Type: Local

Path (1)

Hop (1)

Address: 122.x.x.x:5061

Destination (1)

Alias (1)

Type: Url

Origin: Unknown

Value: sip:[email protected]

StartTime: 2014-02-19 01:06:14

Duration: 0.04

SubSearch (1)

Type: Transforms

Action: Not Transformed

ResultAlias (1)

Type: Url

Origin: Unknown

Value: [email protected]

SubSearch (1)

Type: Admin Policy

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: [email protected]

SubSearch (1)

Type: FindMe

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: [email protected]

SubSearch (1)

Type: Search Rules

SearchRule (1)

Name: Local zone – no domain

Zone (1)

Name: LocalZone

Type: Local

Protocol: SIP

Found: False

Reason: Not Found

StartTime: 2014-02-19 01:06:14

Duration: 0

Gatekeeper (1)

Address: 112.x.x.x:0

Alias (1)

Type: E164

Origin: Unknown

Value: 4980

Zone (2)

Name: LocalZone

Type: Local

Protocol: H323

Found: False

Reason: Not Found

StartTime: 2014-02-19 01:06:14

Duration: 0

Gatekeeper (1)

Address: 112.x.x.x:0

Alias (1)

Type: E164

Origin: Unknown

Value: 4980

SearchRule (2)

Name: Local zone – full URI

Zone (1)

Name: LocalZone

Type: Local

Protocol: SIP

Found: False

Reason: Not Found

StartTime: 2014-02-19 01:06:14

Duration: 0

Gatekeeper (1)

Address: 112.x.x.x:0

Alias (1)

Type: Url

Origin: Unknown

Value: [email protected]

Zone (2)

Name: LocalZone

Type: Local

Protocol: H323

Found: False

Reason: Not Found

StartTime: 2014-02-19 01:06:14

Duration: 0

Gatekeeper (1)

Address: 112.x.x.x:0

Alias (1)

Type: Url

Origin: Unknown

Value: [email protected]

SearchRule (3)

Name: Traversal zone search rule

Zone (1)

Name: Traversal Zone

Type: TraversalServer

Protocol: SIP

Found: False

Reason: Forbidden

StartTime: 2014-02-19 01:06:14

Duration: 0.03

Gatekeeper (1)

Address: 10.x.x.x:28364

Alias (1)

Type: Url

Origin: Unknown

Value: [email protected]


Thank you for your help.


Acevirgil

Patrick Sparkman Tue, 02/18/2014 - 09:47
User Badges:
  • Purple, 4500 points or more
  • Cisco Designated VIP,

    2017 TelePresence

Paste the search history from the other VCS that it's trying to traverse to for this call. Also, what is the authentication policy set for the traversal zone on the Control?

Sent from Cisco Technical Support iPhone App

deocampo.acevirgil Tue, 02/18/2014 - 10:17
User Badges:

Hi Patrick,


On the Traversal zone on both VCS, I changed the authentication policy from "Check credentials" to "Do not check credentials" and now it works.


Issue was resolved but our problem is we cannot login on the VCS Expressway using Jabber client. Internal jabber can successfully login on the VCS control.


Right now the VCS servers athentication policy were configured this way:


VCS Control:

Default subzone: check credential

Default zone: check credential

Traversal zone: do not check credential


VCS Expressway:

Default subzone: check credential

Default zone: check credential

Traversal zone: do not check credential


What should be the proper configurations of the authentication policy on each zones on bothe VCS?


All authentication were authenticated on the VCS local database.


Thank you.


Br,


Acevirgil

Patrick Sparkman Tue, 02/18/2014 - 10:25
User Badges:
  • Purple, 4500 points or more
  • Cisco Designated VIP,

    2017 TelePresence

Glad you got it figured out, I had a similar instance not too long ago testing authentication methods. The Control should be set to check, while the Expressway should be do not check. The provisioning deployment guide can help in setting up the Control and Expressway zones for authentication.

Sent from Cisco Technical Support iPhone App

deocampo.acevirgil Tue, 02/18/2014 - 10:49
User Badges:

Hi Patrick,


On the VCS Control:


Default subzone: check credential

Default zone: check credential

Traversal zone: check credential




On the VCS Control:


Default subzone: do check credential

Default zone: do check credential

Traversal zone: do not check credential


The Jabber on the extenal can login again but our previous problem encounterd again.



Thanks,


Acevirgil

Patrick Sparkman Tue, 02/18/2014 - 10:54
User Badges:
  • Purple, 4500 points or more
  • Cisco Designated VIP,

    2017 TelePresence

Are you trying to authenticate to the Control or Expressway. Typically, authentication would be proxied to the Control and done there. Are there any sub zones in place for the Jabber Video users?

Sent from Cisco Technical Support iPhone App

deocampo.acevirgil Tue, 02/18/2014 - 11:06
User Badges:

Hi Patrick,


All authentication should be on the VCS Control. No zubzones yet for Jabber users.

Do we need to create subzones for jabber users on the Control or in Expressway?


Thanks,


Acevirgil

Patrick Sparkman Tue, 02/18/2014 - 17:53
User Badges:
  • Purple, 4500 points or more
  • Cisco Designated VIP,

    2017 TelePresence

The subzone comment was just trying to find out if maybe if you had any, those authentication settings would also affect how a Jabber Video user logs in.


In our environment, the Expressway is set to do not check for all zones, the Control is set to Check for all zones.  Which include the Default Subzone, Traversal Zone, etc.  Do you have the SIP domain configured on the Expressway?  I'm running out ideas, maybe someone else might have something in mind, I'd run through the provisioning deployment guide to try and double check all of the configurations.

Correct Answer
Daniel Isham Tue, 02/18/2014 - 21:21
User Badges:

I definitely recommend creating a subzone for Movi, as you can also control bandwidth also. I never register anything to the default subzone on the Expressway and disable registration for security purposes. Movi clients register to their own subzone

nes along with subzones for other specific things.


For security sake, I don't like not checking for credentials on the Expressway, especially if you have a ISDN gateway or perhaps the Control has a route out to the PSTN. Toll fraud is not sweet.


I always have deployed SSO via LDAP vs local authentication. It gets tricky when you can't join the Expressway to the domain but still want to authenticate and check credentials. The trick is you need to create a local user on Expressway, then actually create the same identical username and password in active directory. Then in TMS, push out these credentials using the configuration template for the version / device of MOVI.

deocampo.acevirgil Tue, 02/18/2014 - 21:49
User Badges:

Hi Daniel,


Thank you for some inputs and recommendations.


Default Zones, subzones authentication policy on both VCS are set to "Check credentials" except for Traversal zone set as "do not check credentials/treat as authenticated" on the servers.


Yeah, your right. In our case, we used to create authentication database for Jabber users on the VCSe identical with the credentials made on TMS provisioning and works fine now. Eventually we will be integrating the VCS servers with AD for centralized authentication and more secure environment.


Thank you.


Br,


Acevirgil

Actions

This Discussion