Weird ragistration with VCS-C from endpoints behind NAT

[marekjp2450]

I have a VCS-E (Starter Pack) and VCS-C both installed on public Internet.

I know it is un-orthodox but I have valid reasons to try such setup.

My operation serves endpoints at random locations - basically, general public.

EPs connect over Internet links provided by a variety of ISPs or over 4G wireless

from several providers (actually, all of them). So, this is essentially public

H323/SIP network rather than enterprise setup with users call from behind every

conceivable firewall/NAT device.

I realize I could support such service using VCS-E devices but, as it  happens,

I have a bunch of VCS-C devices with large licenses. I have always assumed that

VCS-C differs from VCS-E by essential functions such as only supporting Traversal

Client zones or lack of internal user account database and FindMe. None of this

would prevent me from using VCS-C as described. In reality, VCS-C refused to work

with certain clients more often than not. The same clients connecting to VCS-E

work just fine.

After a day or two of troubleshooting I found the following: When endpoint registers

with VCS-E, both RAS and Apparent RAS addresses point to public  IP from Internet

provider, as they should:

RAS address                              108.22.12.158:12345

Apparent RAS address                    108.22.12.158:12345

Now, the SAME  EP registers with VCS-C as follows:

RAS address                              192.168.2.77:12345

Apparent RAS address                    108.22.12.158:12345

This obviously cannot work and it doesn't.  I can fix it by activating H323 ALG on

the firewall but what do I do with "naive" users of the system?

Obviously, VCS-E and VCS-C software handle "from behind NAT" registrations differently.

VCS-C handling is clearly incorrect. How come? Is this a bug or intentional "sales

support" ruse? How can I make VCS-C to handle calls from behind NAT the way VCS-E

or StarterPack do?

[Paulo Souza]

Hi,

VCSc cannot provide firewall traversall features to your external endpoints behind a firewall/NAT because it does not has ability to act as a traversal server, it works only as a traversal client. Only VCSe works as a traversal server.

As a traversal server, VCSe supports some special protocol which provide advanced abilities to firewall/NAT traversal, such as Assent, H460.18/19, TURN and ICE. That's why VCSe can work fine even with endpoints behind a NAT/firewall.

So, if you want to provide firewall traversall to your external endpoints, you will need to use VCSe, otherwise it won't work correctly. I don't think ALG can help in this case, because you will probably have endpoint behind simple firewalls which cannot provide inspection features.

If your endpoints is benhind a NAT/firewall whose external IP address is static, you could configure NAT address on endpoints configuration, but this may be a issue with certain kind of endpoints and when external NAT address is not static, or when using SIP. But be aware that the best option is to have VCSe providing firewall/NAT traversal.

There is an old document from Tandberg that brings a nice explanation about firewall traversall (Assent and H460) and NAT, this one:

http://www.cisco.com/en/US/docs/telepresence/endpoint/mxp-series/white_papers/tandberg_h323.pdf

You can also check VCS Administrator Guide to find more information on firewall traversal features:

http://www.cisco.com/en/US/products/ps11337/prod_maintenance_guides_list.html

I hope this help.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[marekjp2450]

Paolo,

thanks a lot for your reply. I think though that we are not exactly on the same page. It is possible I haven't explained the issue clearly enough.

I do understand Expressway concept very well.  I agree that Expressway is a very good solution to firewall traversal problem for enterpise. It is not really applicable in my situation. I don't deal with a large number of VTC users on a corporate LAN calling out/in but with a number of users behind consumer grade NAT/firewall devices trying to REGISTER with a VCS.   The problem is NOT a firewall traversal issue at all. It is a much simpler issue of proper implementation of VCS interaction with NAT.

In my example I have an endpoint on a private network trying to register with 1st VCS-E and then with VCS-C. Never mind making calls eventually. I just want to register and I assume responsibility for getting my signalling across my firewall/NAT. When I do that, I discover that VCS-E handles this simple operation correctly, while VCS-C registration is nonsensical since it sets up RAS address to a non-routable network:

VCS-E

RAS address                              108.22.12.158:12345

Apparent RAS address             108.22.12.158:12345

VCS-C

RAS address                              192.168.2.77:12345

Apparent RAS address             108.22.12.158:12345

This, IMHO, is not "lack of support for firewall traversal" but a bug . Or sabotage, if you will.  By any name, VCS-C is not able to properly handle registrations - which are needed to connect calls later - from any device behind NAT. I also observe  that since VCS-C maintains the notion of RAS and Apparent RAS, its basic design assumed accepting connection from NATted devices.

Consider the following: a company network uses private addresses 192.168.xxx.yyy and has a VCS-C sitting on it. The company has a secret lab using the 10.aaa.bbb.ccc network, and the two are separated by  a router-NAT device. VCS-C couldn't handle calls from the lab to the rest of company LAN, could it?

As a sideline, an H323 ALG on the NAT router fixes the issue right away. This is not a solution for my use case, though.

Is there anything I can do to fix this w/o spending my niece college fund on a pair of VCS-E devices?

[Paulo Souza]

Hi Marek,

Sorry If I misunderstood your description, I guess there is some lack of information about your topology, maybe that's why I didn't get your problem very well.

Ok, tell me, what are the IP addresses configured on the interfaces of VCS-C and VCS-E? Is there any dual nic option enable? Are you using NAT address? Do you have a firewall between your VCS's and internet?

Take a look at this information:

VCS-E
RAS address                              108.22.12.158:12345
Apparent RAS address             108.22.12.158:12345
VCS-C
RAS address                              192.168.2.77:12345
Apparent RAS address             108.22.12.158:12345

The same IP address on both VCS's, is that correct?

...while VCS-C registration is nonsensical since it sets up RAS address to a non-routable network:

Well, lets say VCS-C has its LAN1 configured with the IP address 192.168.2.77, if that is true, then VCS-C really should set RAS address as 192.168.2.77. But if VCS has LAN1 configured with the IP address 108.22.12.158, so there is no reason to have 192.168.2.77 in RAS setup, unless you have a firewall with ALG/inspection replacing the address, or if you setup your VCS-C with dual nic option (what makes no sense at all, once this option should only be used with VCS-E).

To make sure that VCS-C is putting the correct IP address within H323 messages, you can capture the logs in VCS-C itself before the messages reach the firewall, then you can see how the messages generated by VCS-C looks like, including the IP address inside H323 headers. Can you do it?

Consider the following: a company network uses private addresses 192.168.xxx.yyy and has a VCS-C sitting on it. The company has a secret lab using the 10.aaa.bbb.ccc network, and the two are separated by  a router-NAT device. VCS-C couldn't handle calls from the lab to the rest of company LAN, could it?
As a sideline, an H323 ALG on the NAT router fixes the issue right away. This is not a solution for my use case, though.

Well, VCS-C cannot work in this kind of topology without having ALG. In order to have the communicaton working, VCS-C needs to put the NAT IP address inside H323 headers, because if VCS puts its local address, endpoints in the other side will answer to this local address, then, the communication won't work. VCS-C should put NAT IP address insite H323 headers, but here is the point, VCS-C cannot do that! VCS-C will always put its local address inside all H323 and SIP headers. Only VCS-E can be conifgured to put the NAT address inside H323 and SIP headers, so that endpoints in the other side will answer to the NAT address of VCS-e, then the communication will work fine. VCS-E is able to use this setup when you enable dual nic feature, with this feature you can setup a NAT address on VCS-E itself, but this option is not made to VCS-C, only to VCS-E.

When I stated "VCS-C cannot provide firewall traversall", I was also refering to this behavior of VCS-C.

The same concept applies if you have VCS-C on internet using a local address behind a firewall making NAT to a external IP address.

I may be missing some points of your problem, it is because I didn't understand your issue 100%.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[marekjp2450]

Paolo,

thanks a lot for your reply - it clarifies few items for me. Let me answer your questions, though, so we can close the discussion for benefit of other users of the forum .

[Paolo in blue] Ok, tell me, what are the IP addresses configured on the interfaces of VCS-C and VCS-E? Is there any dual nic option enable? Are you using NAT address? Do you have a firewall between your VCS's and internet?

Both VCSes ae on a public Internet. No dual nic option in the EXPWY. No NAT, no firewall.  The simplest possible case.

Take a look at this information:

VCS-E

RAS address                              108.22.12.158:12345

Apparent RAS address             108.22.12.158:12345

VCS-C

RAS address                              192.168.2.77:12345

Apparent RAS address             108.22.12.158:12345

The same IP address on both VCS's, is that correct?

Two adjecent addresses on the same subnet. My endpoints register from behind a consumer-grade NAT, though.

...while VCS-C registration is nonsensical since it sets up RAS address to a non-routable network:

Well, lets say VCS-C has its LAN1 configured with the IP address 192.168.2.77, if that is true, then VCS-C really should set RAS address as 192.168.2.77. But if VCS has LAN1 configured with the IP address 108.22.12.158, so there is no reason to have 192.168.2.77 in RAS setup, unless you have a firewall with ALG/inspection replacing the address, or if you setup your VCS-C with dual nic option (what makes no sense at all, once this option should only be used with VCS-E).

To make sure that VCS-C is putting the correct IP address within H323 messages, you can capture the logs in VCS-C itself before the messages reach the firewall, then you can see how the messages generated by VCS-C looks like, including the IP address inside H323 headers. Can you do it?

VCS-C is on Internet, so your scenario does not apply. I fully agree with the merit of your comment, though. Actually, this is the gist of my question. Why would VCS-C use private address as RAS address while being located on public Internet?  This cannot work, and it does not.  I could fire up Wireshark but not knowing if I can fix the problem by, say, configuring some setting on VCS-C that I overlooked, I'm disinclined.

From your comment I  understand that you essentially agree with me in the puzzling matter of RAS address being on private network while VCS-C is on Internet. Do you? Especially that VCS-E - with same code base - behaves correctly.

Consider the following: a company network uses private addresses 192.168.xxx.yyy and has a VCS-C sitting on it. The company has a secret lab using the 10.aaa.bbb.ccc network, and the two are separated by  a router-NAT device. VCS-C couldn't handle calls from the lab to the rest of company LAN, could it?

As a sideline, an H323 ALG on the NAT router fixes the issue right away. This is not a solution for my use case, though.

Well, VCS-C cannot work in this kind of topology without having ALG. In order to have the communicaton working, VCS-C needs to put the NAT IP address inside H323 headers, because if VCS puts its local address, endpoints in the other side will answer to this local address, then, the communication won't work. VCS-C should put NAT IP address insite H323 headers, but here is the point, VCS-C cannot do that! VCS-C will always put its local address inside all H323 and SIP headers. Only VCS-E can be conifgured to put the NAT address inside H323 and SIP headers, so that endpoints in the other side will answer to the NAT address of VCS-e, then the communication will work fine. VCS-E is able to use this setup when you enable dual nic feature, with this feature you can setup a NAT address on VCS-E itself, but this option is not made to VCS-C, only to VCS-E.

When I stated "VCS-C cannot provide firewall traversall", I was also refering to this behavior of VCS-C.

The same concept applies if you have VCS-C on internet using a local address behind a firewall making NAT to a external IP address.

I may be missing some points of your problem, it is because I didn't understand your issue 100%.

Actually, I appreciate your reply very much. On a practical level my question essentially was: am I doing something wrong, or is this how VCS-C works? Now I know. I managed to design a workaround. I can get where I want to be using ALG on the client-side firewall. This works just fine on all wireless broadband and with ISP providers such as Verizon FIOS, and I'm doing it from a small add-on to my EP software. This covers 90% of my users, which is good enough.

To close the case, please, let me state that I fully understand both technology and sales model behind VCS-E and VCS-C. I just don't think that setting up incorrect RAS address serve any useful purpose in separating VCS-E and VCS-C functionalities.

Regards

Paulo Souza

Same here!  It was a pleasure.

[Alok Jaiswal]

Hi Marek,

As Paulo mentioned VCS-C can't provide the firewall traversal. Also we don't have any option to have dual interface option key for the VCS-C.

So better you have to use VCS-Exp for providing firrewall traversal solution to external clients or don't use NAT.

You can also procure VCS starter pack if your deployment is small.

Hope it helps.

Rgds

Alok

[Martin Koch]

In addition to what Paulo and Alok wrote.

It would be interesting if you define "large licenses"

VCSc appliances come by standard with 100 Traversal calls.

But these are not to be used how you seem to expect it.

there are many postings around that here in the forum and also info here:

http://www.cisco.com/en/US/docs/telepresence/infrastructure/articles/vcs_traversal_call_license_usage_kb_168.shtml

But if you need to traverse firewall (or better said NAT) you need the expressway

functionality of the VCS-E, rather than the traversal call license on the vcs-c.

So yes if you want to register endpoints directly from unknown networks with firewalls, nat, ... ,

thats exactly what will prevent you of using a VCS-C.

It is not the traversal server for an other vcs its the NAT handing of direct registered clients.

Many people forget hat small offices or homes might come via a NATed connection which

is exactly one of the deployment models for the VCS-E.

So it sounds a bit that there is some room to improve the understanding of the expressway functionality :-)

This,  IMHO, is not "lack of support for firewall traversal" but a bug . Or  sabotage, if you will.  By any name, VCS-C is not able to properly  handle registrations - which are needed to connect calls later - from  any device behind NAT. I also observe  that since VCS-C maintains the  notion of RAS and Apparent RAS, its basic design assumed accepting  connection from NATted devices. 

Not that some might start thinking that what you are trying to do is license misuse. ;-)

VCS-C and -E have the same code base and sure its mainly a license thing, but with all licensing,

you get what you pay for.

Deplotment for a vcsc:

registered devices with direct, non firewalled and especially non nated connection in between ALL the endpoints

the standard call flow is a local call with media flowing directly in between the devices.

VCSE:

media will be bound to vcse, traversal calls are used for these systems behind nat (more see above link)

So VCS-C in your deployment as the main/only registrar = failed deployment.

Please check out the admin and deployment guides for a better understanding!

Consider  the following: a company network uses private addresses 192.168.xxx.yyy  and has a VCS-C sitting on it. The company has a secret lab using the  10.aaa.bbb.ccc network, and the two are separated by  a router-NAT  device. VCS-C couldn't handle calls from the lab to the rest of company  LAN, could it? 

Thats fine, some companies have seperated networks and security zones, you would then deploy

a VCS-E in the inside network where (in your case the labnetwork) could connect to. Either the

endpoints directly or you place an additional vcs-c in the lab and use a traversal zone inbetween both.

As a sideline, an H323 ALG on the NAT router fixes the issue right away. This is not a solution for my use case, though.

I will not exlude that you might find a ALG/SBC which might work, but that is not the best practice

deployment and I would be not be to surprised if there is no official support for it if you run into trouble.

[marekjp2450]

Martin Koch wrote:
In addition to what Paulo and Alok wrote.
It would be interesting if you define "large licenses"
VCSc appliances come by standard with 100 Traversal calls.
But these are not to be used how you seem to expect it.
there are many postings around that here in the forum and also info here:
http://www.cisco.com/en/US/docs/telepresence/infrastructure/articles/vcs_traversal_call_license_usage_kb_168.shtml
Hmm... is one traversal license used up by a call traversing a traversal zone? And a non-traversal license is one that is not a traversal license since there sre only two of them, unless one is out of non-traversal licenses not passing traversal zone, in which case a traversal license can be substituted for a no-traveral one? If yes, I got it right. 
Sometimes I however find myself pondering about the role of semantics when I notice that while VCS-C/VCS-E combo is marketed as a firewall traversal solution, it is not at necessary for a call to traverse the traversal expressway to count as a traversal call. Go figure. What confuses me to no end though is the fact that VCS Expressway needs VCS Control to provide expressway across the firewall but, at the same time, VCS Control is not called VCS Expressway. What? Never mind.
But if you need to traverse firewall (or better said NAT) you need the expressway
functionality of the VCS-E, rather than the traversal call license on the vcs-c.
I guess I said this in my initial message. Would you mind looking it up?
So yes if you want to register endpoints directly from unknown networks with firewalls, nat, ... , 
thats exactly what will prevent you of using a VCS-C. 
Actually, I managed to get around it by figuring out how to activate H323 ALG from my endpoint on several most popular NAT/FW/Routers from Verizon etc. I always believed that there are very few things in networking you truly cannot do.
It is not the traversal server for an other vcs its the NAT handing of direct registered clients.
Well, I said this, too! It wasn't an issue with firewall traversal, but something as simple as correctly setting RAS address upon registration. It was really hard for me to believe that Tandberg/Cisco couild get such a basic operation wrong.
Many people forget hat small offices or homes might come via a NATed connection which 
is exactly one of the deployment models for the VCS-E.
So it sounds a bit that there is some room to improve the understanding of the expressway functionality :-)
This is not helpful.  This is a technical forum, isn't it?
This,  IMHO, is not "lack of support for firewall traversal" but a bug . Or  sabotage, if you will.  By any name, VCS-C is not able to properly  handle registrations - which are needed to connect calls later - from  any device behind NAT. I also observe  that since VCS-C maintains the  notion of RAS and Apparent RAS, its basic design assumed accepting  connection from NATted devices. 
Not that some might start thinking that what you are trying to do is license misuse. ;-)
Ugh! Would you please elaborate on this one? Oh, I get it. When I connect to VCS-C from my LAN, traverse the FW using EXPWY and make VCS-E place a call for me, it is OK. If I however manage to bypass VCS-C silly design, connect to it from behind NAT, and place a call - this is license misuse. In which case I want my money back.
VCS-C and -E have the same code base and sure its mainly a license thing, but with all licensing, 
you get what you pay for.
Deplotment for a vcsc:
registered devices with direct, non firewalled and especially non nated connection in between ALL the endpoints
the standard call flow is a local call with media flowing directly in between the devices.
VCSE:
media will be bound to vcse, traversal calls are used for these systems behind nat (more see above link)
So VCS-C in your deployment as the main/only registrar = failed deployment.
Please check out the admin and deployment guides for a better understanding!
Martin, I'm way past reading VCS guides. Incidentally, they are a bit better than most industry manuals, so giving them once-over is enough. My interest is on a different plane, namely, trying to understand how exactly has Tandberg managed to architect a bunch of devices so as to be able to sell seemingly infinite number of different licenses. This is a very educational case in technology sales. I love it when I get a piece of the Telepresence tech and very quickly find out that the functionality I just happen to need requires another license. It is a masterpiece. I can't help myself trying to get around it!  - all within terms of the licenses, of course.
Consider  the following: a company network uses private addresses 192.168.xxx.yyy  and has a VCS-C sitting on it. The company has a secret lab using the  10.aaa.bbb.ccc network, and the two are separated by  a router-NAT  device. VCS-C couldn't handle calls from the lab to the rest of company  LAN, could it? 
Thats fine, some companies have seperated networks and security zones, you would then deploy
a VCS-E in the inside network where (in your case the labnetwork) could connect to. Either the
endpoints directly or you place an additional vcs-c in the lab and use a traversal zone inbetween both.
That's right! All I need is another $17K license. Which is exactly the point I tried to make. Very perceptive.
As a sideline, an H323 ALG on the NAT router fixes the issue right away. This is not a solution for my use case, though.
I will not exlude that you might find a ALG/SBC which might work, but that is not the best practice 
deployment and I would be not be to surprised if there is no official support for it if you run into trouble.
Martin, do I sound to you as a guy in need of a cutomer support contract? 
In closing, I got all the help I needed from Paolo. It helped me to solve my problem and so I can continue using VCS-C to support a deployment that it is not supposed to support. To be on the safe side though I just bought on eBay a bunch of Border Controlers in working condition for ~$65 apiece, licenses included.
Best,