Cisco VCS error: Temporary failure / New connection needed

[federico.battaglia]

Hi all,
I write this new message to ask a support in the installation of VCS system (VCS Expressway + Control).
In my case I have 4 levels of firewalling (Juniper A - Checkpoint - Expressway - Checkpoint - Juniper B - Control), where A is the outer Juniper that realizes the NAT.
At present I can make calls in both directions only if I place the external video-terminal between Juniper A and Checkpoint (with private address). If I try to put the video-terminal outside the Juniper A enabling NAT on this FW and enable the application NAT on the Expressway (with the public IP), the call rings but when the internal video-terminal accepts the call, for it the call is connected (no audio/video), while the caller continues to ring as if no one had answered.
Going to see the logs on the systems I have this message in the VCS:

Temporary failure / New connection needed

and going to see the details that I have:

Call disconnected, Message sent, Datail = "Q.931 Cause temporary failure, H.225 Cause: New connection needed, Additional Info: None"

Has anyone ever had this problem? Someone who can help me to locate where is the error?
Thank you very much!

greetings
Federico

[awinter2]

Frederico,

in general you want to make sure that your firewalls are not interfering with or in any way modifying the H323 and SIP payloads as the traffic traverses between VCS-C, VCS-E and the outside world. This means disabling H323 and SIP ALG/inspection.

Also, if the VCS-E is behind a NAT, make sure that you install the dual network interfaces option on the VCS-E and configure Static NAT properly.

Apart from these general pointers, we would have to capture diagnostics logs from the involved VCS's and look at a detailed network diagram to get some further insight into the problem.

[federico.battaglia]

Hi all,

and thanks for the replies received.

@Andreas: analyzing the configuration of the external FW with whom I have found that problems, are enabled the following ALG:

SIP

RTSP

Q931

RAS

H245

Now I want to ask: I have to turn off ALL these or only some of them? Surely the SIP, but the others? I think yes. Can you give me feedback?

greetings

[awinter2 · Accepted solution]

Federico,

for traffic between VCS-C and VCS-E, the following ALG's could have an impact:

SIP

Q931

RAS

H245

In other words, all of those you listed apart from RTSP. I'd recommend you disable SIP, Q931, RAS and H245 ALG's, at least for traffic exchanged between VCS-C and VCS-E.

Let us know how it goes

- Andreas

[federico.battaglia]

Tnx Andreas.

the fw that causes me problems, however, is that between the expressway and the external terminal (on the internet).

In fact, if I connect the terminal before the FW II have no problems.

The call through other FW on my network but these have the ALG disabled, the last one instead do not (have the status that I have reported).

I'll disable the ALG on external FW as you indicated me and I check (I hope) if everything works as if I called before the FW.

I'll let you know

Federico

[federico.battaglia]

Hi Andreas,

whitout the ALGs as above mentioned the call goes up (both direction). : )

I'm very happy.

But now i have another problem... when i have tried to replicate the configuration of lab-fw on the production-fw:

- the incoming call works well but the outcoming call don't work

on the vcs control i obtain this status: Channel unacceptable

you have any suggestions for me?

[awinter2 · Accepted solution]

'Channel Unacceptable' is normally also related to network/firewall.

To properly understand what is happening for the outgoing call scenario, we would have to see diagnostics logs with Network log level set to 'DEBUG' from both the Control and Expressway for the call in question.

- Andreas

[federico.battaglia]

Hi Andreas,
I did check and test. The situation now is as follows:

I have tested the calls in both directions using a similar FW to that of production. Everything works perfectly.

I tested the calls with production FW and work only incoming calls. For outgoing ones we have: the call comes in, the message connected appear but then the pop-up freeze. It's like the FW lock up part of the flow, but on it there are no blocks.
On the expressway the status of the call is "Normal, unspecified", while on the Control status is "Channel unacceptable".

It’s to keep in mind that the traffic on the test FW and on the FW production perfectly follows the same path, but is divided only when it arrives on these FW. We have a video-out terminal that using the test FW and one using the production FW. So, I think, the only network error could be in the FW rules since the routes, for the choice of which FW must be used, are correct. But if the problem is on the FW rules we should see the blocks on the FW (which they aren’t).

The only differences (for now I identify) between the two FW are:

- On production FW Microsoft RPC ALG is active while on another one no (but I don’t think has to do with anything)
- On production FW is set, for the Untrusted zone, many screen (set Untrust screen ...); but it seems strange that this will lead to not work the only outgoing calls

Any idea? I want to enable the DEBUG log on Expressway and make a traffic capture today if I  can’t identify the problem. Maybe with this I find more information.

A greeting and thanks to all who answer me

[awinter2]

Federico,

can you clarify what you mean by 'On production FW is set, for the Untrusted zone, many screen (set Untrust screen ...);'?

If you are planning to take logs, make sure to grab a diagnostics log (Network log level = DEBUG) from both the VCS-C and VCS-E, since we would need to compare the H323 messages as they are sent and received to understand whether or not the FW is altering any of the payload data for these messages.

Another good test to check for H323 ALG is to disable the H323 part of the traversal zone between VCS-C and VCS-E and ensure that the SIP part of the traversal zone uses TLS. Now when you place a call across the traversal zone (and through the FW), the SIP signaling will be encrypted and the FW will not be able to inspect/modify any traffic (in general at least, there are FW's which can inspect TLS as well but that's not very common) and calls will then normally work.

- Andreas

[Patrick Pettit]

Hi Federico - If your SIP Traversal Zone isn't coming online, I would turn it off on VCS Control and Expressway and start network log debug on both and then reenable.  SIP OPTION Ping would be sent from Expressway to Control via port specified on Traversal Zone.  If this OPTION Ping is not responded to by VCS Control, this will more likely mark your zone for SIP as inactive and generate that warning - systems unreachable. Leave the network log debug run for a few minutes so we can see the traffic if any. 

If your still getting no media between control and expressway and the endpoints involved, would be good to see a simultaneous sniff from control and expressway as the problem occurrs.  Also, its very important as Andreas said to remove any H323 and SIP ALG/Inspection on your checkpoint firewall. 

Let us know if you go this route, and if you upload them to your support case, so we can have a closer look. 

Thanks in advance.

VR

Patrick

[federico.battaglia]

@Patrik: the traversal is properly activated and if I place the external video-terminal before the last FW everything works

properly. Surely I'll follow your advice if I don't get improvements disabling the ALG mentioned above.