Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 3 subscribers
  • Views 1299 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Idea for Toggling Site-2-Site VPN on/off

seroal
Hi!

A customer needs a special feature, which I think, is not available so far...

He wants some users to be able to toggle specific vpn tunnel on and off and vice versa on the astaro. But they shouldn´t get access to the firewall or only to enable/disable the tunnel. I think thats not possible OOTB?

I think it should be a way, thats supported by astaro, but probably, that will be difficult... I´m thinking about a script on the firewall, thats executable and uses cc to activate or deactivate a vpn connection. But propably its not allowed to create users in passwd....?!

Do you have an idea?


Sebastian


This thread was automatically locked due to age.
Parents
  • 0
    The reason we found that this would have been useful was that we have a development team who need from time to time access a client connection over a number or ports and by a number of developers.  

    An SSL VPN was not suitable as more than one developer generally needed access.  The process for approval of a site2site vpn needed lots of approvals which had been satisfied when the VPN was first created.  Subsequently the need for access was infrequent, so best practices suggest that the VPN be turned off when not in use.  

    It made sense to us to suggest that a "VPN manager" was appointed from the development team who should be able to turn off their managed VPNs from the User Portal, much in the same way as HTML5 access shows up when allowed.

    This approach would be useful in both directions so that a company which had occasional requirements for outside support would be able to use such a system from their side ie turning off unneeded access to their application for outside developers after support was completed as well as situations such as ours when we wanted to go the other way.

    Identifying a VPN manager gave the responsibility where it was needed and kept system administrators from having to respond to simple on/off requests during their busy workloads.

    As mentioned in my earlier post, it was simple, didn't need a new design to host it, existing framework was in place, promoted good security and was something the competition didn't provide.  Win/win!
Reply
  • 0
    The reason we found that this would have been useful was that we have a development team who need from time to time access a client connection over a number or ports and by a number of developers.  

    An SSL VPN was not suitable as more than one developer generally needed access.  The process for approval of a site2site vpn needed lots of approvals which had been satisfied when the VPN was first created.  Subsequently the need for access was infrequent, so best practices suggest that the VPN be turned off when not in use.  

    It made sense to us to suggest that a "VPN manager" was appointed from the development team who should be able to turn off their managed VPNs from the User Portal, much in the same way as HTML5 access shows up when allowed.

    This approach would be useful in both directions so that a company which had occasional requirements for outside support would be able to use such a system from their side ie turning off unneeded access to their application for outside developers after support was completed as well as situations such as ours when we wanted to go the other way.

    Identifying a VPN manager gave the responsibility where it was needed and kept system administrators from having to respond to simple on/off requests during their busy workloads.

    As mentioned in my earlier post, it was simple, didn't need a new design to host it, existing framework was in place, promoted good security and was something the competition didn't provide.  Win/win!
Children
No Data