Easy way to make a website accessible only by VPN?
December 6, 2012 6:10 PM
How can I setup a website accessible by VPN but by multiple users at different locations? More details inside...
I have a client that needs a website whose users will be a small group (less than 10) of data-entry users at five difference locations, all on different networks.
Is there a solution out there that is simple: i.e. -- click to connect to website via VPN -- that won't make it a headache to support these users?
The requirements of the project state that the website can only be accessible via VPN.
My research is coming back with several complicated setups...
I have a client that needs a website whose users will be a small group (less than 10) of data-entry users at five difference locations, all on different networks.
Is there a solution out there that is simple: i.e. -- click to connect to website via VPN -- that won't make it a headache to support these users?
The requirements of the project state that the website can only be accessible via VPN.
My research is coming back with several complicated setups...
If the users are all connecting to a single VPN with a pre-set IP address / IP range, then you can set a firewall filter to block all but those IP addresses.
We need more details before we can really give advice though - what is the current set up like (in terms of existing VPNs, location of the VPN relative to the web server, other websites running on the web server etc).
posted by titantoppler at 6:38 PM on December 6, 2012
We need more details before we can really give advice though - what is the current set up like (in terms of existing VPNs, location of the VPN relative to the web server, other websites running on the web server etc).
posted by titantoppler at 6:38 PM on December 6, 2012
Unfortunately these are all users at different organizations so there is no existing VPN that unifies these users.
If there were no VPN requirement here they would all simply connect to an SSL website and enter data. So I guess the question here is what could the VPN layer be that would be simple to get them setup with?
Thanks for the questions and follow-ups.
posted by thorny at 6:49 PM on December 6, 2012
If there were no VPN requirement here they would all simply connect to an SSL website and enter data. So I guess the question here is what could the VPN layer be that would be simple to get them setup with?
Thanks for the questions and follow-ups.
posted by thorny at 6:49 PM on December 6, 2012
From work experience. I have a client (client company/software is Juniper Networks) that has a supplier (vendor) site that makes suppliers log in once to begin running the java/activex applet for a VPN program. This then makes the next link available that provides access to the supplier tools to respond to the client's requests.
This VPN program is distributed by the website only and installs once on the client machine. However it can have issues with some corporate proxies as I have found. Any sort of independent connection though is smooth sailing.
posted by Bodrik at 8:28 PM on December 6, 2012
This VPN program is distributed by the website only and installs once on the client machine. However it can have issues with some corporate proxies as I have found. Any sort of independent connection though is smooth sailing.
posted by Bodrik at 8:28 PM on December 6, 2012
This requirement seems really poorly thought out. I'd push back hard on it and see if you can get at the underlying reason for requiring the VPN. I suspect that what they really want is encryption of the data in transit, but someone thought that "encryption" = "VPN" so the requirement got written up that way.
There's not any benefit, at least that I can see from what you've described so far, in setting up a VPN for a bunch of arbitrary clients, so they can connect to a single website. That's not what a VPN is for. That's what SSL/TLS is for, and most VPN implementations that you'd probably end up using would use the exact same sort of encryption that a straightforward TLS transport would.
Yes, there are some VPN solutions that basically embed the VPN client in an ActiveX control, deploying it and taking over the client's workstation (basically) when they go to a particular website without much user interaction. But they have a number of drawbacks (in particular, off the top of my head: they almost always require Windows / IE, they require the site to be trusted and IE has to allow ActiveX controls). They're not terrible solutions for road warrior situations (giving people on the road access to resources in a home office / network) but it's entirely overkill for wrapping a single website's traffic.
Don't go down that road without making it blisteringly clear that it's contrary to best practices and likely to increase downstream maintenance risk, as well as upfront costs (most of the easy-to-use solutions are proprietary), and that there's an equally-secure, standards-based, less-expensive solution available. Most of the time in my experience, the same sort of morons who blindly push requirements as-written will back down if they have to put their ass on the line by making a call like that.
posted by Kadin2048 at 11:17 PM on December 6, 2012
There's not any benefit, at least that I can see from what you've described so far, in setting up a VPN for a bunch of arbitrary clients, so they can connect to a single website. That's not what a VPN is for. That's what SSL/TLS is for, and most VPN implementations that you'd probably end up using would use the exact same sort of encryption that a straightforward TLS transport would.
Yes, there are some VPN solutions that basically embed the VPN client in an ActiveX control, deploying it and taking over the client's workstation (basically) when they go to a particular website without much user interaction. But they have a number of drawbacks (in particular, off the top of my head: they almost always require Windows / IE, they require the site to be trusted and IE has to allow ActiveX controls). They're not terrible solutions for road warrior situations (giving people on the road access to resources in a home office / network) but it's entirely overkill for wrapping a single website's traffic.
Don't go down that road without making it blisteringly clear that it's contrary to best practices and likely to increase downstream maintenance risk, as well as upfront costs (most of the easy-to-use solutions are proprietary), and that there's an equally-secure, standards-based, less-expensive solution available. Most of the time in my experience, the same sort of morons who blindly push requirements as-written will back down if they have to put their ass on the line by making a call like that.
posted by Kadin2048 at 11:17 PM on December 6, 2012
Is there a solution out there that is simple: i.e. -- click to connect to website via VPN -- that won't make it a headache to support these users?
Depending on your budget, there are hardware devices that will solve this problem nicely. The term to search for is SSL VPN. There are devices that only do SSL VPN, or it can come as a feature of a firewall. Note that this is different from OpenVPN, which is a software package (though OpenVPN is also definitely a viable option here. Take a look at the docs).
In general, SSL VPN appliances are usually rack mounted hardware devices. You plug one side into your DMZ (or what have you) and the other side into your internal network. There is a web interface. Users hit the web interface and download a plugin. ActiveX or Java usually, but it can also be an executable like Cisco AnyConnect. Sometimes you can choose, depending on what features you need. The plugin is deployed on the client with routing policies you define. After installation, relevant traffic from the client is tunnelled over port 443, goes over the internet to the appliance, is de-encapsulated, and then forwarded on to its destination. More detail.
Not knowing more specifics about your situation, I'm not going to make any particular recommendations, so here are just some random examples of right sized devices that do what I'm talking about: Cisco ASA5500, Juniper SA2500, Palo Alto Networks PA200, Barracuda Networks SSL VPN Model 180, Sonicwall SRA 1200, Watchguard SSL 100.
There is a big spread in terms of pricing on the examples above (some are below $1K, some can get around 4 or 5) so you should shop around and find what fits your budget. The devices I have named are just off the top of my head. Lots of vendors in this space, lots of price points.
On the Sonicwall SRA 1200 I will say it sucks and I think SonicOS is hot nonsense, but it mostly works and is super cheap. Cisco is Cisco and Juniper is Juniper, which is to say they are both feature rich and expensive. Palo Alto Networks gear is fucking rad and awesome. The rest I have no comment.
Finally, there are also virtual machine appliances from many of the same vendors that do the same thing and can be more cost effective if you have pre existing infrastructure to work with. And if you want to get a little creative there are other ways to solve this problem, for example Microsoft Remote Desktop Gateway, which is RDP tunnelled over SSL. Like others above, I question the requirement for VPN here. A better option would be to secure your webapp properly and lock it down by access IP.
tl;dr: SSL VPN.
posted by tracert at 11:28 PM on December 6, 2012
Depending on your budget, there are hardware devices that will solve this problem nicely. The term to search for is SSL VPN. There are devices that only do SSL VPN, or it can come as a feature of a firewall. Note that this is different from OpenVPN, which is a software package (though OpenVPN is also definitely a viable option here. Take a look at the docs).
In general, SSL VPN appliances are usually rack mounted hardware devices. You plug one side into your DMZ (or what have you) and the other side into your internal network. There is a web interface. Users hit the web interface and download a plugin. ActiveX or Java usually, but it can also be an executable like Cisco AnyConnect. Sometimes you can choose, depending on what features you need. The plugin is deployed on the client with routing policies you define. After installation, relevant traffic from the client is tunnelled over port 443, goes over the internet to the appliance, is de-encapsulated, and then forwarded on to its destination. More detail.
Not knowing more specifics about your situation, I'm not going to make any particular recommendations, so here are just some random examples of right sized devices that do what I'm talking about: Cisco ASA5500, Juniper SA2500, Palo Alto Networks PA200, Barracuda Networks SSL VPN Model 180, Sonicwall SRA 1200, Watchguard SSL 100.
There is a big spread in terms of pricing on the examples above (some are below $1K, some can get around 4 or 5) so you should shop around and find what fits your budget. The devices I have named are just off the top of my head. Lots of vendors in this space, lots of price points.
On the Sonicwall SRA 1200 I will say it sucks and I think SonicOS is hot nonsense, but it mostly works and is super cheap. Cisco is Cisco and Juniper is Juniper, which is to say they are both feature rich and expensive. Palo Alto Networks gear is fucking rad and awesome. The rest I have no comment.
Finally, there are also virtual machine appliances from many of the same vendors that do the same thing and can be more cost effective if you have pre existing infrastructure to work with. And if you want to get a little creative there are other ways to solve this problem, for example Microsoft Remote Desktop Gateway, which is RDP tunnelled over SSL. Like others above, I question the requirement for VPN here. A better option would be to secure your webapp properly and lock it down by access IP.
tl;dr: SSL VPN.
posted by tracert at 11:28 PM on December 6, 2012
Thanks to all for the responses. It is always hard filtering out the BS on the internet with search results and appreciate the knowledge. I am going to work with the client to make sure they realize what is necessary to accomplish their goals and if they still want to move forward, this will be helpful.
posted by thorny at 1:06 PM on December 7, 2012
posted by thorny at 1:06 PM on December 7, 2012
This thread is closed to new comments.
posted by bitdamaged at 6:33 PM on December 6, 2012