VCS Control and VCS Expressway design

[e.lopessilva]

I have an implementation where I have 2 VCS Control and 1 VCS Expressway software version X6. The end costumer has a Internet firewall Fortinet woroking in routed mode with NAT. My question is about the placement of the VCS Expressway in the environment. Is it mandatory put the Expressway in front of the firewall with a Internet valid IP address on it? Is it possible put the Expressway behind of the firewall and configure a NAT for it? Make sense having VCS control and VC expressway in the IP subnet without NAT between them?

Thanks in advance.

Everaldo

[Marwan ALshawi]

Hi Anreas,

This article looks like stating or implying no static nat but either a DMZ with public ip not nated DMZ

Or the other option you mentioned with two interfaces where one ip can be places in a not anted DMZ and the other interface in private DMZ

Personally I had issue with one interface with static nat one to one with ASA till got it changed to non nated DMZ things fixed

Which is I believe stated clearly in the above article ! Let me know if I missunderstood anythingnhere ?

Regards,

[Martin Koch]

Like Andreas stated, its possible to have the VCS-E behind a static 1:1 nat, but then you need the

dual interface option. Even if you only use one interface, as this also enables the NAT ip address configuration.

If there is NAT in between the VCS-C and VCS-E or not does not matter.

Both would work fine out of the box with the traversal zone.

If the VCS-E (towards the public, for example on a private ip) is behind 1:1 NAT or two interfaces

(one internal one public) are required, the dual interface option is needed.

You find some more information in the VCS admin guide.

Martin

[awinter2]

Marwanshawi,

also please note that the article at

http://www.cisco.com/en/US/docs/telepresence/infrastructure/articles/vcs_benefits_placing_expressway_dmz_not_public_internet_kb_196.shtml has been modified and now contains more detailed information about placing the VCS in a DMZ and/or behind a static NAT.

[Marwan ALshawi]

Thanks Andreas and Martin

But the two interfaces option with one to be placed in the public is not accepted by most of the customers due to the security risk

If the two interfaces option chosen then one interface can be placed in a not NATed DMZ,  public IPs only which will make sure there is no firewall bypass from security point of view

[awinter2]

Marwanshawi,

with the dual network interfaces option key installed on your VCS-E, you will have quite a lot of flexibility in terms of how you deploy the VCS-E:

- Using 1 network interface in a DMZ with a publicly routable IP address

- Using 1 network interface in a DMZ with a private IP address with Static NAT enabled

- Using 2 network interfaces in one or more DMZ's with a publicly routable IP address assigned to the externally-facing interface

- Using 2 network inerfaces in one or more DMZ's with private IP addresses assigned to both interfaces with Static NAT enabled

In any scenario where both NIC's are used, it is recommended that these interfaces have IP addresses in different subnets. It is also recommended that any firewalls which carry traffic to and from this VCS-E is not performing any sort of SIP and H323 application inspection/fixup as this might interfere with the built-in firewall traversal functionality (H.460 and Assent) of the VCS-E.

Hope this helps,

Andreas

[Marwan ALshawi]

Thanks :)

[e.lopessilva]

Andreas,

Could you tell me what would be the options with a license for just one LAN interface actived?

Tks,

Everaldo

[awinter2]

Hi Everaldo,

assuming that with "license for just one LAN interface", you mean not having the dual network interfaces option key, the only supported option is to assign LAN 1 with a publicly routable IP address not behind any sort of NAT (If connectivity with public networks/Internet is required, that is).

[Marwan ALshawi]

Agree with Andreas and if you refer to my first post you will see same recommendation !

[Ricardo Sicheran]

So say I have a dsl in bridge mode.  Then I will have to connect my VCS Starter Pack's only NIC to it and assign public ip to it.

So my internal endpoints will have to register through the public internet to get to this VCS-E?

Can you elaborate on how a call to username@cisco.com finds their VCS?  For SIP is it just the two domain records _sip_ , _sips that need to resolve to your VCS outside address?

Do you have any solutions in a scenario where SIP traffic through a firewall needs to go to a CUBE setup for SIP trunk provider while video traffic needs to go to the VCS with option key enabled for NAT?

[awinter2]

Ricardo,

yes your endpoints would then have to register with the public IP address of your Expressway.

The VCS will, as you state, use DNS SRV records for locating remote gatekeepers/SIP proxies, you can find more details about which records are used in the VCS Admin guide.

I'm not too familiar with CUBE and which DNS SRV records usually point to the CUBE, and I guess if the VCS and CUBE "share" similar SRV records that could pose a problem.

For the VCS, it is most common to receive SIP calls over TCP or TLS, e.g _sip._tcp and _sips._tcp.

Hope this helps,

Andreas

[Muthurani Lavanya Paneerselvam]

Marwan, Thanks for sharing. Very helpful, 5+

Regrads

Lavany

[vipersl65]

Dont forget in your Control Traversal zone to point the peer to the public IP of the Expressway

[maciej_wilk]

Hi,

What about the following scenario?

If the VCS Expressway is in DMZ 2 with a private IP address will I need the Dual Network Interface Option?

From this topic I understand that yes but why can't it work without the option?

What configuration is necessary on Expressway for it to work?

And which IP do I point the VCS Control to? Private IP 192.168.x.x or NATed 212.212.x.x?

Unfotunately there is not much information in documentation for such deployments.

Thanks for help

Maciek

[awinter2]

Maciek,

the reason why the VCS-E will need the dual network interfaces option key while deployed in DMZ is because you will need the static NAT feature of the VCS-E for this deployment to work.

In H323 and SIP, call signaling and media addresses are embedded into the signalling payloads of the H323 and SIP messages, and when the VCS-E is located behind a NAT, these payloads need to be altered to contain the public NAT IP of the VCS-E to ensure that external parties are able to reach the VCS-E when attempting to set up signaling and media exchange.

For instance, if you were to place a call from an endpoint registered to the VCS Control towards an endpoint at a remote location (For example username@cisco.com), the call would be proxied via the VCS-E. Without using the static NAT feature of the VCS-E, the VCS-E would tell the remote endpoint to send media to the 192.168.x.x address which the VCS-E is assigned with (References to the 192.168.x.x address would be made inside H323/SIP messages). This would obviously not work, but with the static NAT feature of the VCS-E, the VCS-E would replace those embedded IP address references withthe public address 212.212.x.x, which means that the remote endpoint would send relevant traffic to this address instead, and connectivity should work properly (Assuming you have also configured the static NAT properly on the edge firewall/router.

Also, as vipers points out, using the above diagram as an example, where you are using only the LAN1 interface of the VCS-E, you would have to enable static NAT on this interface and configure the traversal client zone on the VCS-C with 212.212.x.x as the peer address in order for this to work.

Hope this helps,

Andreas