Just a thought...

[packet46]

A lot of network equipment that is manufactured these days has a web interface. Like, Nokia FW's and various VPN Concentrators.

Seeing as how the code for these web interfaces is held locally on the network device, would it not be a good idea for SecureCRT to offer a HTTP/S interface to network devices that are so enabled?

I think it would be really good if you can have a console session to a network node, like a Nokia FW, on one tab and also a secure web browser interface to run the Nokia Voyager application on another.

Like with a Nokia (and I know I'm banging on a bit here..) you cannot edit the routing table via the console session, only through the Voyager interface which is HTTP/S only.

I see this as an excellent step for Van Dyke to gain more market share over network products.

Anyone agree/disagree?

[dcomo]

Interesting thought, however I feel that it is impractical. If this was going to happen, I would imagine that VanDyke would implement a browser rather than write one from scratch. (They could use Mozilla or rely on the Internet Explorer libraries to achieve such as task.)

However, the software would then 'bloat' and be sucseptable to vulernabilities within the implemented software.

I personally manage a slew (600+) devices which many have different configuration interfaces. Yes, most of them are SSH-based, however I do have the occasional web-based interface that uses HTTPS. I don't mind firing up Firefox for said case.

I love SecureCRT how it currently is, nice and lean. I'd really prefer not to see a browser built into it.

That's my 2 cents...

[MrC]

I would disagree with such a direction as well. It is critical that SecureCRT/CRT remain foremost secure, and as fast and lean as possible.

There are already excellent, fully capable browsers that can be used.

Personally, I don't understand this drive to cram all functionality into all apps. Each application has its place, strenghts, and weaknesses.

If you really need to see your applications under one roof (so to speak), perhaps you can consider getting a virtual screen manager, and place all you SecureCRT sessions and appliance console browser sessions on a single virtual screen. Then, just pretend that the bottom of your monitor is your tabbed window (the Windows taskbar): Voila!, everything under one tabbed interface! :-)

Seriously, the minor convenience gain vs. the risks, feature bloat, expanding beyond VanDkye's core skills and loss of focus in my opinion would be an unworthy and unwise undertaking.

Just my 2c also.

[toloughlin]

In addition, if you try to implement a web tab, what happens to the emulation of the other tabs? Should the new https tab take control of the emulation? Unfortunately I feel that this may be somewhat of an unnecessary feature.
Then again, I've been known to be completely wrong

[packet46]

I can sort of see your argument against vulnerability and bloatware exposure. But the "I want SecureCRT to stay just the way it is" argument is a little rooted in the past isn't it??

We're not talking servers here, just a web client. It can be written in house to minimalise security holes and keep the amount of code to a minimum. It can use open source and bolt that down.

Surely the power & performance of the local host will control the application function and not the application itself? Assuming the applet is written correctly and manages CPU cycles and memory associations correctly.

As for emulation compatabilities, the web client would be running in it's own environment on the local host. So a connections to server A from client B running on SSH and HTTPS will not combat each other. They are separate TCP flows to the same IP address.

I just think it allows the application to be THE application of choice for network and system administrators by offering more functionality to a wider degree of devices.

I do not include netbios or CIFS based servers here, just network nodes.

Life goes on...maybe I'll write something similar...

Cheers.

[bocks]

Originally Posted by packet46

Seeing as how the code for these web interfaces is held locally on the network device, would it not be a good idea for SecureCRT to offer a HTTP/S interface to network devices that are so enabled?

I think it would be really good if you can have a console session to a network node, like a Nokia FW, on one tab and also a secure web browser interface to run the Nokia Voyager application on another.

Like with a Nokia (and I know I'm banging on a bit here..) you cannot edit the routing table via the console session, only through the Voyager interface which is HTTP/S only.

This is a feature that has been requested before. If you would like to have your contact information added to the feature request for HTTP/HTTPS support to be added to SecureCRT, I just need to get yur contact information.

Rather than post it here on the Web, please send a message to Support@vandyke.com with a subject of Attn: Shannon Re: Forum thread ID 842

Once I get your message, I will add your contact information to the feature request so that we will be able to notify you if a future release of SecureCRT contains this ability.

Thanks,

-bocks

[packet46]

I apologise if I am being too demanding here, buut sometimes idea's just hit me and I note them down.

Here's another....

Recently I set up a couple of site-to-site VPN tunnels for a client of mine. Now a few years ago, I worked with VPN Concentrators (Cisco, Nortel, Juniper) when the IPSEC config was laboured and tricky. Now it is very, very simple to build such a tunnel. Normally, the default settings for Phase 1 (IKE) and Phase 2 (IPSEC) of a VPN tunnel are used because they are so reliable.

Only a pre-shared key need be configured at either end for authentication.

Building on my previous post of harnessing all that wasted processing power on your average desktop/laptop computer, could VanDyke not create a default settings connection type of "VPN".

Really this would require one screen which had Phase 1 and Phase 2 settings options.

In my mind, as long as the 'Perfect Forward Secrecy' [PFS] option was not used (this encrypts the IP header and makes routing on internal corporate LAN's difficult) then using SecureCRT with this function would enable client to server VPN tunnels to be constructed for remote maintenance and would negate the need for expensive over priced "VPN Concentrators" and would endear VanDyke into the hearts of many a network / sysadmin.

Obviously there would be other things to think about but I will happily get involved with the testing of such a function.

Cheers
Dave H

[gan]

Originally Posted by packet46

Recently I set up a couple of site-to-site VPN tunnels for a client of mine. Now a few years ago, I worked with VPN Concentrators (Cisco, Nortel, Juniper) when the IPSEC config was laboured and tricky. Now it is very, very simple to build such a tunnel. Normally, the default settings for Phase 1 (IKE) and Phase 2 (IPSEC) of a VPN tunnel are used because they are so reliable.

Only a pre-shared key need be configured at either end for authentication.

Building on my previous post of harnessing all that wasted processing power on your average desktop/laptop computer, could VanDyke not create a default settings connection type of "VPN".

Really this would require one screen which had Phase 1 and Phase 2 settings options.

In my mind, as long as the 'Perfect Forward Secrecy' [PFS] option was not used (this encrypts the IP header and makes routing on internal corporate LAN's difficult) then using SecureCRT with this function would enable client to server VPN tunnels to be constructed for remote maintenance and would negate the need for expensive over priced "VPN Concentrators" and would endear VanDyke into the hearts of many a network / sysadmin.

Obviously there would be other things to think about but I will happily get involved with the testing of such a function.

I'm not sure if i understand exactly what you request, but every vendor got their own implementation of VPN and their own features. That's why every major vendor got their own client as well. So then vandyke would have to create software for both the client and server end to make it work. I cannot see how that would be helpful in any way. If you need a secure connection they already got products that support SSH like vshell, etunnel and securecrt that i believe will to what you request except it's not IPSec. Also a lot of network equipment like most cisco routers support ssh as well to connect directly to the equipment.

Cheers