01-07-2013 12:04 PM - edited 03-18-2019 12:23 AM
Hi all,
We use a single TMS installation to manage multiple endpoints (mainly C and MXP series) across multiple institutions and network boundaries. Whilst the institutions are able (in the most part) to allow us direct 1:2:1 NATed address to endpoints behind their firewalls, this is becoming increasing more difficult and convoluted.
It would be great if we could either:
Regards
Chris
01-08-2013 12:26 AM
The TMS needs to be reachable and run on the standard ports 80/443, but besides that,
the behind firewall mode should work ok.
Example, you have a TMS on a public ip and endpoints in a remote office behind one single nat router.
In this case management is still possible and endpoints can get configurations and phonebooks.
The management is less responsive as the endpoint now polls the config from the TMS rather then
the TMS pushing commands out to the endpoint and some things might be limited (no reboots, updates can not be forced, limitations regards booking, ...) but its better then nothing.
You also would have the option for some endpoints to use provisioning instead the system navigator style setup.
But yes, I see there could be some major improvements to make it easier to handle NAT.
Please remember to rate helpful responses and identify
01-08-2013 01:52 AM
Hi Martin and thanks, but I haven't quite explained myself properly.
It's not the reachability of TMS so much that bothers me, indeed our TMS install is accessible publicly via standard web ports. Its more about how you can add end point into TMS.
Your example is pretty accurate: we have multiple endpoints behind various firewalls with many of thier remote access ports NAT'ed (mainly SSH and HTTPS). When you add an endpoint into TMS, you can only specify its IP address. It would be great if you could specify a IP address and port (such as xxx.xxx.xxx.xxx:port), then at the firewall/access router, forward that port to the relevant endpoint and service you wish it to be reachable on. In this way, multiple endpoints could be added to TMS that sit behind a firewall and share a single public IP.
such that:
PublicIP:4433 --> 10.0.0.10:443
PublicIP:4434 --> 10.0.0.11:443
PublicIP:4435 --> 10.0.0.12:443
etc
Provisioning would be nice to be extended to the C, SX and MXP series, but currently is only available for Jabber and the E20, EX and MX series. It would be great if ALL endpoint setting were modifiable and available for the the endpoint to poll and pull from TMS including things such as reboots. However, if forwarded port could be implemented, then we would still be able to access the remote management interfaces of the endpoint using standard IP address and port notation from a browser and or shell program such as Putty.
Of course another option would be a way to push out configs and commands via the VCS infrastructure - but I guess this is what the provision extension would do (something I have't looked at yeat as we don't operate any of the necassary endpoints.
Chris
01-08-2013 03:27 AM
Though TMS can not handle stuff well behind nat it might be helpful for you to have access
via the webinterface of the endpoint or ssh connection to it to manually do some action.
You have some things you could check on regards the systems behind firewall:
* pre add systems based on the serial number
* enable auto discovery for soho in tms
* add dhcp option 242 to point to the TMS
or manually add the tms ip (external mamager) on the endpoint (osd, via ssh/web session ...)
Then at least the systems show up automatically in TMS.
And to repeat me and what you say as well:
Yes, I see there could be some major improvements to make it easier to handle NAT/Firewalls :-)
Please rate the answers using the stars below!
Please remember to rate helpful responses and identify
01-08-2013 10:48 AM
Hi Chris,
It is unlikely that we'll ever see significant improvements in TMS's handling of remote systems. The core TMS application's handling of remote systems has largely been superseded by the Provisioning Extension / VCS Expressway's management model, which is both more flexible and more scalable.
Provisioning will never be extended to the MXP series; these systems won't get any new software features as they are end-of-sale. TMSPE provisioning of SX and C series should work just fine, as long as you create the necessary schemas yourself. That's easily doable by tweaking an EX template. (Not officially supported by the Cisco TAC, though).
Regards,
Kjetil
01-09-2013 12:55 AM
TMSPE provisioning of SX and C series should work just fine, as long as you create the necessary schemas yourself. That's easily doable by tweaking an EX template. (Not officially supported by the Cisco TAC, though).
As Kjetil says, this is not...repeat...is not a supported solution. Until the SX and C-Series folks provide an official schema so has to be able to provision these EPs with the TMSPE solution, this will not be supported by the Cisco support services.
rgds,
Dale
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