02-18-2014 08:27 AM - edited 03-18-2019 02:36 AM
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
Solved! Go to Solution.
02-18-2014 09:21 PM
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.
02-18-2014 08:51 AM
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?
02-18-2014 09:19 AM
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:4995@sample.com" Dst-alias-type="SIP" Dst-alias="sip:4980@sample.com" 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="4995@sample.com" Dst-alias-type="SIP" Dst-alias="sip:4980@sample.com" 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:4995@sample.com" Dst-alias-type="SIP" Dst-alias="sip:4980@sample.com" 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="4995@sample.com" Dst-alias-type="SIP" Dst-alias="sip:4980@sample.com" 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: \1@sample.com
Thanks,
Acevirgil
02-18-2014 09:22 AM
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.
02-18-2014 09:40 AM
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: 4995@sample.com
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:4980@sample.com
StartTime: 2014-02-19 01:06:14
Duration: 0.04
SubSearch (1)
Type: Transforms
Action: Not Transformed
ResultAlias (1)
Type: Url
Origin: Unknown
Value: 4980@sample.com
SubSearch (1)
Type: Admin Policy
Action: Proxy
ResultAlias (1)
Type: Url
Origin: Unknown
Value: 4980@sample.com
SubSearch (1)
Type: FindMe
Action: Proxy
ResultAlias (1)
Type: Url
Origin: Unknown
Value: 4980@sample.com
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: 4980@sample.com
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: 4980@sample.com
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: 4980@sample.com
Thank you for your help.
Acevirgil
02-18-2014 09:47 AM
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
02-18-2014 10:17 AM
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
02-18-2014 10:25 AM
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
02-18-2014 10:49 AM
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
02-18-2014 10:54 AM
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
02-18-2014 11:06 AM
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
02-18-2014 05:53 PM
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.
02-18-2014 09:21 PM
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.
02-18-2014 09:49 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide