Jump to content


Photo

Java in the browser...


  • Please log in to reply
38 replies to this topic

#21 sorin

sorin
  • Members
  • 52 posts

Posted 16 May 2017 - 03:54 AM

Bud Gifford, on 15 May 2017 - 7:41 PM, said:

The product was purchased with implications that it would continue to be developed at least to the point that it would continue to work for its intended purpose

 

This is what I try to explain but I was not able to put it in English as Bud did.

That is what to be considered by Barracuda Networks and I hope that we are not the only two clients that remained till now to use the SSL VPN appliance.

I would really like to here what is the situation with the rest of the SSL VPN users. What is their using experience and what solutions did they implemented in order to make it work.



#22 Gavin Chappell

Gavin Chappell
  • Moderators
  • 426 posts
  • LocationNottingham, UK

Posted 16 May 2017 - 03:55 AM

Network Connector has a standalone client​. True, but can you run that without the administrative credentials?

Absolutely. The Standalone Network Connector client requires admin rights only at installation time. The regular web-launched Network Connector client requires admin rights at run time, every time, in order to correctly configure network routes. The standalone client has always been the better way to go for environments which restrict admin rights, and the standalone Network Connector client can be installed and configured via Group Policy in a properly managed corporate environment.
 
 

”which has an identical workflow” - NOT AT ALL. As long as you need administrator credential then you will restrict dramatically the number of the machines that can use the servce only to those you are administrating.

I was referring here to the workflow of the Standalone SSL VPN Agent vs the web-launched SSL VPN Agent, nothing to do with Network Connector. The Standalone Agent does not require admin rights to install (it can be installed inside a user's profile) or use, with the exception of launching Network Connector because of the network route requirement as detailed above.
 
Just out of interest, I decided to have a look at how other companies define an SSL VPN just in case we differed. Cisco's seems to be:
 

There is a difference between a full VPN tunnel and an SSL-enabled proxy server. The latter is an application gateway that supports a certain type of applications. A complete SSL VPN, on the other hand, is a VPN that provides all VPN characteristics and local LAN user experience (in terms of network access). If application access requirements are modest, SSL VPN does not require additional client software to be installed on the endpoint device. For broader application access, a dynamically downloadable tunneling client is typically delivered when needed to the client machine to support such full SSL VPN capabilities.

I would say that our product fits that definition - modest needs (web forwards) are available clientless, advanced needs (Network Connector, SSL tunnels) require a client that can be downloaded when needed. There's clearly nothing I can tell you here that will close this to your satisfaction other than to repeat my suggestion that if you are unhappy with the continued operation of your SSL VPN then you call our Sales team and discuss a migration plan to a NextGen Firewall with CudaLaunch which may be able to take into account your existing subscriptions.

#23 sorin

sorin
  • Members
  • 52 posts

Posted 16 May 2017 - 04:14 AM

We have not purchased for sure a SSL VPN that fits a definition but a SSL VPN tool with certain features that do not work as advertised any longer.

Otherwise we could have downloaded an open source solution that would fit your definition as well.

 

The problem is that sales team is part of the same defensive ”dream”.

 

The product was purchased with implications that it would continue to be developed at least to the point that it would continue to work for its intended purpose.

So it is a legitimate request to receive a firmware update for the SSL VPN that will make it work for the intended purpose.

 

PS: Please do not forget my reqwest:

Can you please point me towards a tutorial to launch a RDP app or other Application using the Agent standalone app?



#24 Gavin Chappell

Gavin Chappell
  • Moderators
  • 426 posts
  • LocationNottingham, UK

Posted 16 May 2017 - 04:32 AM

Can you please point me towards a tutorial to launch a RDP app or other Application using the Agent standalone app?

  • Nothing changes on the SSL VPN itself, your resource is configured the same way
  • You need to download the correct version of the Standalone Agent from your SSL VPN portal (it appears under the User Downloads tab)
  • Install the Agent - this can be done system-wide if you are an administrator, or in your profile if you are not
  • During the installation, provide the hostname of your SSL VPN appliance
  • I think the Agent automatically runs after installation, if not then run it manually
  • The standard key icon will appear in the notification area, but with a red X over it showing that you are not logged in
  • Right click on the key and choose Login
  • Your default web browser will open at the login page of your SSL VPN, where you can log in using your normal credentials (including multi-factor authentication if this is configured)
  • Once you have completed the login process, the key icon will lose its red X overlay
  • At this point you can launch Agent resources as normal, either by clicking the link in the web browser or by right clicking the Agent icon and using the menu


#25 sorin

sorin
  • Members
  • 52 posts

Posted 16 May 2017 - 05:16 AM

OK. Thank you. Done that with the Standalone Agent

The only big disadvantage is that it has to be installed and requires administrator credentials.

 

I think the debate on the topic went far from the purpose of the forum and somehow is more a topic regarding product development that a technical one.

Thank you very much for all support.

I will try further to contact a Product manager or somebody that oversees the entire development process for both SSL VPN and F-Series Firewall and find a suitable solution.



#26 Gavin Chappell

Gavin Chappell
  • Moderators
  • 426 posts
  • LocationNottingham, UK

Posted 16 May 2017 - 05:36 AM

The only big disadvantage is that it has to be installed and requires administrator credentials.

This is not true - the installation and use for RDP should be possible without administrative privileges. At which point did you think these are required?



#27 sorin

sorin
  • Members
  • 52 posts

Posted 16 May 2017 - 07:17 AM

if I will download sslvpn-agent-windows-x86_64.exe from the SSL VPN portal then the user will have to install it manually which is not straight forward at all.

It will have to configure as well the server ...

and above all the entire pack will remain on the computer if not uninstalled manually

that means that if there is a key logger on that computer is easy to access the resources

also that means extra time from our support side to teach the users to install and configure the agent

 

not straight forward at all



#28 Gavin Chappell

Gavin Chappell
  • Moderators
  • 426 posts
  • LocationNottingham, UK

Posted 16 May 2017 - 07:28 AM

if I will download sslvpn-agent-windows-x86_64.exe from the SSL VPN portal then the user will have to install it manually which is not straight forward at all.

This can be automated via Group Policy if desired, there is more information on the Campus page.
 

It will have to configure as well the server ...

This can also be automated as above, with the user free to override the default setting if they need to
 

and above all the entire pack will remain on the computer if not uninstalled manually

This is not much different to the web-launch Agent which will remain in the user's profile (C:\Users\username\.sslvpn) by default - arguably the Standalone Agent approach is better with a single copy of the Agent binaries per-system instead of a copy per-user
 

that means that if there is a key logger on that computer is easy to access the resources

This is a stretch. If a system has a keylogger on it, then someone could be logging credentials and log in through the web anyway. To say that the Standalone Agent is more susceptible to keylogger behaviour than the web-launch Agent is absolutlely wrong.
 

also that means extra time from our support side to teach the users to install and configure the agent

This can be automated via Group Policy, and even on machines requiring manual installation (for example a user's home computer) this can generally be as simple as Next, Next, Next, Finish.



#29 Bud Gifford

Bud Gifford
  • Members
  • 18 posts

Posted 16 May 2017 - 08:08 AM

My concern is not a keylogger.  However, the stand alone agent is just not an option for us.  Our non-technical users cannot install the stand alone agent.  They have tried and failed.  Heck, I have done it and have it fail on more than one occasion.  It is a pain to do.  As a Dev you may think not, but from our view-point it is a pain.  And we do not want the agent on some of users PCs for "certain reasons".   And it comes down simply to this.  Had we wanted an agent solution we would have bought something else besides the SSL VPN.  But, we want the web interface and the way it works, um, worked and not "the other solution" with an agent that keeps getting pushed so hard, when it is not suited for our needs. 



#30 Bud Gifford

Bud Gifford
  • Members
  • 18 posts

Posted 16 May 2017 - 08:12 AM

BTW, we have never had one of users successfully install the stand alone agent on their own.  And with our small staff, we do not have to do it for them on laptops.  And we sure do not have time to visit their homes for their desktops.



#31 Bud Gifford

Bud Gifford
  • Members
  • 18 posts

Posted 16 May 2017 - 08:20 AM

Well, this thread is going no where.  It is just defensive replies trying to make me use the product in a way different from what I bought it to do.  Fact is that it does not do what we need it to do any longer.  So, to me it is an EOL product for my purposes other than security patches and bug fixes. Looking for another solution.  This is so not typical for Barracuda and I hope this is not the direction the company is beginning to go from now and in the future. Signing out from the thread. 



#32 Gavin Chappell

Gavin Chappell
  • Moderators
  • 426 posts
  • LocationNottingham, UK

Posted 16 May 2017 - 08:25 AM

My concern is not a keylogger.  However, the stand alone agent is just not an option for us.  Our non-technical users cannot install the stand alone agent.  They have tried and failed.  Heck, I have done it and have it fail on more than one occasion.  It is a pain to do.  As a Dev you may think not, but from our view-point it is a pain.  And we do not want the agent on some of users PCs for "certain reasons".   And it comes down simply to this.  Had we wanted an agent solution we would have bought something else besides the SSL VPN.  But, we want the web interface and the way it works, um, worked and not "the other solution" with an agent that keeps getting pushed so hard, when it is not suited for our needs. 

 

I'm not a developer either, I'm part of the Support team for the SSL VPN and I'm not aware of many cases with the Standalone Agent failing to install. Not wanting the Standalone Agent on users PCs makes very little sense - the code is shared between the Standalone Agent and web-launch Agent so any reason you may not want the Standalone Agent on a user's computer must also extend to the web-launch agent.

 

The reason that I'm trying to persuade you to try the Standalone Agent is because that is the solution that was decided upon to this problem. You said above that "Had we wanted an agent solution we would have bought something else besides the SSL VPN", but the Agent has always been required for certain features of this product and nothing has changed there. We still have an agent available which enables this functionality. No vendor can make a truly clientless SSL VPN system offering TCP tunnels because this functionality is not provided by pure HTML, and while our Java approach has pros and cons, it is very deeply ingrained into this product and the only solution to it would be to build a new product (which is almost exactly what we are doing with the Remote Access functionality on the NextGen Firewall product).

 

Well, this thread is going no where.  It is just defensive replies trying to make me use the product in a way different from what I bought it to do.  Fact is that it does not do what we need it to do any longer.  So, to me it is an EOL product for my purposes other than security patches and bug fixes. Looking for another solution.  This is so not typical for Barracuda and I hope this is not the direction the company is beginning to go from now and in the future. Signing out from the thread.

I'm sorry you feel that way; as I've said to sorin previously, feel free to speak to the Sales team. As a non-Sales guy I cannot myself promise any discounts, however if you still have a substantial period of time to run on any SSL VPN subscriptions you have then there may be a deal to be done there with regards to trading in for one of the NextGen Firewall products.



#33 sorin

sorin
  • Members
  • 52 posts

Posted 18 May 2017 - 03:59 AM

Dear Garvin,

 

apparently, me and Bud, we are the only remaining Barracuda`s clients to use the SSL VPN so maybe you are under the impression that it is kind of funny to play with us.
I think my approach was quite decent but I do not believe that is a reason to be taken as a fool or as a puppet.
At last in my case I already tried to discuss with sales team and as I mentioned to you before they have no other solution either. So please do not send the people to discuss with sales team. Maybe you should inform yourself better before send us to put some more money in BARRACUDA`s pocket.
It was a mistake on my side to invest in BARRACUDA. The marketing policy of BARRACUDA makes that the Total Cost of Ownership to overcome even the top brands.
You leave your clients to believe that they pay a fair price in the beginning but in the end, they have to pay even more because you just stop developing the product.
It is a lesson learned by me and I will promote that in my network of procurement experts so everybody would be aware of such things are happening.


#34 sorin

sorin
  • Members
  • 52 posts

Posted 18 May 2017 - 06:26 AM

Here is an example on how to conduct a relieble an serious business:

http://www.cisco.com/c/en/us/products/security/secure-access-control-system/index.html

 

 

End-of-Life Chart

 
Version 5.8
End of Sale 30-Aug-17
End of Software Maintenance 30-Aug-18
End of Support 31-Aug-20


#35 Tim Warr

Tim Warr
  • Members
  • 49 posts

Posted 22 May 2017 - 07:11 AM

Hi Bud and Sorin,

 

Sorry that you feel unhappy about the Barracuda SSL VPN. However, as you mentioned, this thread has possibly got to the end of its usefulness. If you would like discuss this further, please send me a direct message and I will get back in touch.

 

Gavin has provided a lot of details in the thread, but to recap… Over time browsers (all except IE) have been dropping support for java applets. This means that we have had to implement alternative solutions. As explained in more detail in the thread, we have implemented the Standalone Agent as an alternative to running java applets via the browser. Previously we evaluated HTML5 as an alternative to java applets, but found that this would not be a scalable enough solution and does not deliver many of the other features required (e.g. tunnelled web proxies).

 

We continue to support the Barracuda SSL VPN with ongoing Energize Updates and Security features. More details are in https://community.ba...intenance-mode/

 

We also suggest that customers consider evaluating the now more advanced remote access, CudaLaunch and client-to-site VPN features in either the X-Series or F-Series firewall to see if this is also a better solution for your needs. If you would like to pursue this, please reach out to our sales team in order to arrange this.

 

Tim 



#36 sorin

sorin
  • Members
  • 52 posts

Posted 14 June 2017 - 04:09 PM

I see no point in continuing the discution by email.

My statement is clear.

Soon probably we will be informed that bug fixes and security updates are not guaranteed either.

The entire Barracuda maintenance policy prove to be just marketing and dust in the eyes of the customers. 

 

If you have something to communicate please feel free to contact me by email. However since I received no email from you till now probably this message was also just another marketing activity :(

 

Sorin



#37 Alex Trout

Alex Trout
  • Members
  • 1 posts

Posted 27 June 2017 - 06:37 PM

Barracuda Team -

 

Not to put too fine a point on it, but your competitors have managed to implement HTML5 RDP and SSH shortcuts that work very well. While obviously RDP/SSH is only a small piece of the SSL VPN total feature set, it is an important one for a lot of people. I for one would very much like to see Barracuda take another look at implementing it in the SSL VPN product. As an engineer at a Barracuda Partner, I suspect that robust HTML5 RDP functionality would make the SSL VPN product much more interesting for many of our customers.

 

Thanks,

-Alex



#38 sorin

sorin
  • Members
  • 52 posts

Posted 23 September 2017 - 06:59 PM

Hi Alex,

 

 

but your competitors have managed to implement HTML5 RDP and SSH shortcuts that work very well

 

What other rolutions are on the market?

Kind regards,

Sorin



#39 Nick Urban

Nick Urban
  • Members
  • 7 posts

Posted 15 August 2018 - 04:57 PM

As per my earlier post back in 2016, the loss of browser-based resources was a fairly large blow to the feature set I purchased the SSL VPN for. I've struggled with the Standalone Agent since then, but I think Barracuda has underestimated the barrier downloading software presents for many end-users in more controlled industries. Rarely do I get new clients connected without first needing to involve their IT department. This was never the case before the loss of Java. I can't say I blame Barracuda, since obviously Java's deprecation was not their decision, but it absolutely necessitated a change in Barracuda's remote access offerings. Unfortunately, that change never came, and CudaLaunch isn't an improvement in terms of user friendliness. As others have mentioned, HTML5 is the future for simple browser-based access, a technology Barracuda's competitors have been eager to embrace. With my Energize Updates subscription coming to an end, I'm unfortunately looking at other offerings instead of staying with Barracuda. It probably won't impact much, but I'll leave the above thoughts for any Barracuda staff who might wish to consider them.

 

Hi Alex,

 

 

What other rolutions are on the market?

Kind regards,

Sorin

One option is SonicWALL, which makes HTML5 RDP very simple.