VCS Expressway, Status Warning

[federico.battaglia]

Hi all,

I'm writing this message to ask an information about an item that I read on my expressway but I can't understand.

My scenario is a control and a expressway and I want to use them to make calls (and receive), type h323, between my network and the Internet.

I did some test with a device on expressway and one on the control, and then I connected the two vcs with a swicth (without fw). everything works fine.

when I added fw between the two vcs, however, the result is that the call is established, but I don't see anything on the device (video screen black).

On vcs status of calls are "Normal call clearing" and if I see the details it says "call connected".

FWs between the two vcs are checkpoint and no drop is present.

Can someone give me a halp? What could it be?

also, going on expressway I noticed something strange. the page vcs configuration > zones > traversal zones, shown at the bottom this information status:

State: Warning

SIP port: Active

H323 port: Active

Cause: System unreachable

Peer 1: H323 Active: 10.100.1.30:1719

Why is this warning?!? It 's normal or not influential?

[aostense]

Hi Federico,

Normally, this is caused by the Checkpoint firewall, between the VCS-C and VCS-E, if it has H323 fixup enabled. If this is enabled, things like this can happen. So try to disable H323 fixup (if enabled) and see if the error disappears.

Are you using any NAT etc. in this setup? Which ports are opened between the VCS-C and VCS-E?

Is VCS-E placed in a DMZ with all ports (tcp+udp) above 1024 opened (VCS-E <> Internet)?

Hope this helps,

Arne

[federico.battaglia]

Tnx a lot Arne, for your answer.

Well, I have defined the following rules for communication between control and expressway:

TCP-7001 >> SIP signaling

UDP-2776 >> SIP rtp media assent

UDP-2777 >> SIP rtcp media assent

UDP-6001 >> H.323 signaling

TCP-2776 >> H.323 Q.931/H.225/H.245

UDP-2776 >> H.323 rtp media assent

UDP-2777 >> H.323 rtcp media assent

TCP-1720 >> H.460.18/19

TCP-2777 >> H.460.18/19

UDP-50000-52399 >> H.460.18/19

I think that this rule are ok... based on cisco documentation.

Yes, I also think that the checkpoints are giving me some problem. Do you have some tips on this?

No, there aren't NAT on this configuration (when I'll introduce internet-fw, I'll activate NAT feature on expressway).

.

Now I want to run the system without the internet-fw (in fact the external endpoint is directly connected on expressway). Once this work, I'll introduce the internet-fw.

Until now I was able to work perfectly all without fw, now I want to add a fw between control and expressway.

Fed

[aostense]

Hi Fed,

Try to configure the following in your Checkpoint firewall global configuration:

no fixup protocol h323 h225 1720

This normally fixes this issue with Checkpoint PIX firewalls, as the firewall could block the Q931 and H225 signalling (1720 tcp). If you have old software on your PIX, it would be good to update it to the latest software as well (or get a Cisco ASA firewall

You could also use multiplexed ports in this traversal zone (H.460.19 demultiplexing mode=On), and you would then only need the following ports opened from VCS-C to VCS-E:

Media: 2776 udp+tcp

Meida control: 2777 udp+tcp

SIP traversal port: 7001 (default)

H323 traversal port: 6001 (default)

Q931/H225 signaling: 1720 tcp

Between the VCS-E and internet, we recommend to open all ports above 1024 (normally place the VCS-E in a DMZ with all management ports blocked <1024). This is because different endpoints (and client software) use different ports, and you never know which ports device(s) calls in on.

Please take a look at this presentation for more information:

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_IP_Port_Usage_for_Firewall_Traversal_Deployment_Guide_X4_to_X7.pdf

Hope this helps,

Arne

[federico.battaglia]

Arne, thank you very much for your fast and precise answer.

I have found that on the fw-rules appears enabled protocol_type/fixup for the ports of interest.

As soon as I try to disable it for my rule... I can't do this globally on the fw.

I sincerely hope that this will lead to the resolution of my problem.

I'll let you know the result at the end of the tests... hoping, of course, it's good!

Fed

[federico.battaglia]

Hi Arne,

this message to inform you that the result of the test (after putting a ip any-any rule on checkpoint between the control and the expressway) was negative.

Nothing has changed. The call goes up but then the screen is black.

Is possible that inserting a ip any-any rule we have the same problem?

Without FW the system works well.

you have any suggestions?

Fed

[aostense]

Hi Fed,

I wouldn’t think that a “any-to-any allow all” rule would fix this. I would think the Checkpoint has some inspection enabled, and you would need to turn this completely off. H323 fixup, and or SIP ALG (application layer gateways) could in most cases provoke the call to disconnect, no media etc.

So please check your global configuration, and add the suggested line.

Did you also try to enabled multiplexing as well (so that media only uses the 4 ports, 2776 tcp+udp and 2777 tcp+udp)?

If it still doesn’t work after this, you should open a case with Cisco TAC. Then we would need a TCPDUMP from both VCSs while in the call. You can sniff the TCPDUMP from the root shell with the process:

1. login to VCS using ssh, but log in as root rather than admin (this is a linux shell)

2. cd /

3. cd mnt/harddisk

4. mkdir temp_traces (or whatever directory name you want to call it)

5. cd temp_traces

6. start trace by entering (on both VCSs at the same time):

>     tcpdump -s0 -i any -w vcse.pcap (vcse.pcap on VCS-E, and vcsc.pcap on VCS-C)

Replicate issue over 1 min

7. stop trace by typing ^c

* use winSCP or similar to copy the traces from each VCS to your PC

Hope this helps,

Arne