Seeing all the complaints in here of how hard this is to setup brings back memories. I was the lead consultant on a project between a very large US retailer and Centrify to build a product called DirectSecure. It's generally very easy to deploy IPsec policy in a Windows environment via GPO and the customer wanted that to flow down into their nix environments. Centrify, having good hooks in to AD already, was chosen to build a product that did just the same thing in their nix environments by consuming IPsec configuration out of GPO.
While not a sales pitch, and in fact I don't think the product seems to have sold well anyway, it was very interesting to work with them on the test harness we built to validate correct IPsec operations, configuration, validation that data wasn't leaking outside of the SAs that were being provisioned, and performance via the translated policy. The relatable component was this was mainly done against StrongSwan implementations of the IKE daemon if I remember correctly (Linux, AIX and Solaris mainly). I wonder if any of those bits flowed back upstream or if the bolt-on aspect kept that from happening.
StrongSwan isn't complex if you are well versed in IPsec implementation as a whole. It's no more or less complicated than other implementation and is "better" than TLS in it's own right with regard to things that could go wrong. In static environments it's relatively painless once the learning curve is overcome.
That being said I feel like IPsec has a badge it will never get rid of and people discard it before attempting implementation at this point. Hopefully, as mentioned amongst the comments, things like WireGuard will mature and become more mainstream. I very much like the concept carry over that both IPsec and WireGuard can be silent actors within the network not giving away hosts as things like OpenVPN and SSH do. IPsec can, unfortunately, also be implemented to squawk at spurious connection attempts - but at least doesn't rely on the premise as much as things like OpenVPN and SSH do.
And for the record - you can tell someone who's dealt with IPsec extensively since they won't refer to it as IPSec. o_O Microsoft is notorious for getting it wrong.
For an easier way, try Algo. Algo is a set of Ansible scripts that helps you deploy a fully functional StrongSwan IPSEC server with the most secure settings available:
Another great option is the Streisand privacy stack. Streisand sets up a new hosted server running L2TP/IPsec, OpenConnect, OpenSSH, OpenVPN, Shadowsocks, sslh, Stunnel, a Tor bridge, and WireGuard. Once the ansible scripts complete (10-20mins), it shows you an HTML page with client config instructions.
i have a slightly different opinion of ipsec vs tls and this is probably mostly formed because it is being 'abused' where we use it. so we have a bunch of point to point connections to other companies and all of these companies except for one that uses http as its protocol has chosen to use ipsec to protect the connections. it believe it would be much better operationally and in terms of security if these connections were protected by TLS instead.
have a look at how 'rekeying' is done. look at the numerous bugs in strongswan issue tracker related to this. the whole protocol is a shit show and it is really surprising that anything actually works between different vendors.
We use Strongswan to secure host to host connections using pre-shared key when setting up Kubernetes clusters in simple VPS providers like DigitalOcean. This is important since DO, Linode etc does not provide private network. Flannel works with it transparently to provide a Kubernetes-aware ip network.
Containerization is cool, however, if you use policy-based VPN, how do you address the use case with more than 1 strongSwan instance (container) running on the same host, obviously sharing the same host Linux kernel.
I've seen this implemented quite usefully in a corporate environment and for container-container communication; but attempting to set it up for my personal use was an absolute disaster. A bit over a week spent trying to make it work, and it never did.
OpenVPN worked just fine, but I could never make StrongSwan work at all. Which is a shame, I really wanted to have an easy-to-use VPN for my phone and so forth. Settled on OpenVPN, which worked well enough with the iOS clients.
OpenVPN is SSL VPN, relatively easy to setup, it operates in transport layer. strongSwan (IPsec) works in layer 3.
To properly install and configure strongSwan, following the tutorials available over the Nnternet is not enough. One needs to have basic networking knowledge (NAT, iptables in particular), good understanding of IPsec protocol suite (including IKE, AH, ESP), PKI, Linux skills and etc.
> A bit over a week spent trying to make it work, and it never did
I feel your pain. I remember trying to install DNSCrypt[1] on Linux and failing miserably. I was convinced it would work if only I found the right solution online, or if only the right amount of caffeine was in my bloodstream, or if by sheer effort of will I could get it working, but I still failed. I partially got it installed, error messages galore in my terminal, and all my /paths/ were wrong. It was a humbling experience. I quickly uninstalled it as I don't want partially working, broken soft running on my machine.
I guess for this situation a decent OpenVPN client would be ideal like Viscosity[2]
I also could not get an IPSec VPN running on Debian in 2012 (I think it was FreeSWAN), while OpenVPN was no problem. I am planning to run a VPS for VPN and email again and this time looking to do all the setup with Ansible. Two roles came up for StrongSwan when searching: https://github.com/agdsn/ansible-strongswan-serverhttps://github.com/jonathanio/ansible-role-strongswan Not sure how much those help with actual VPN configuation. Anyone have any experience with this?
Well, considering Wireguard says on their website "WireGuard is not yet complete. You should not rely on this code" ... I think the burden is on you to justify the comparison in the first place.
StrongSWAN (and IPSec in general) supports smartcards. WireGuard does not.
I've setup StrongSWAN using smartcards almost 15 years ago, at the time it was the only open source IPSec client that supported it. It was relatively easy to get going (the server was a Cisco VPN appliance, which I managed and it was relatively easy to extract the relevant IKE profiles).
For L2TP-over-IPSec, support for mobile devices, like iOS/Android, and relative simplicity of configuration for users (e.g. through provisioning profiles).
I would like to try that instead of a Linux implementation - it would be a great help if you would like to link to some (working) tutorials... of course I found something on search engines, but I expect to find many outdated things (as always with these kind of knowledge), so a link to THE right thing would be a very lovely shortcut. Thanks!
Yeah, I moved over to OpenBSD from FreeBSD because of their no-bullshit approach to supporting IPSEC -- everything just worked out of the box.
I was thrilled when FreeBSD added IPSEC support in 11-RELEASE, but was less excited to learn that IPSEC_NAT_T wasn't compiled in, making it impossible to use strongswan. Oh well, maybe in 11.1 :)
I set this up a few weeks ago on a linux vps I'm using for dev. IPSEC with IKEV2 and certificates. Native clients on windows 10 and Ubuntu laptop (needed a network-manager plugin to be built), and took the shortcut and used the StrongSwan app on android.
The process was complex and there are things I still don't understand but it does work and the documentation and examples are quite comprehensive. The only issue I had with them was they assume a fair amount of familiarity with subjects that I didn't have. I'm mainly a serverside developer not a network admin, and whilst I have a vague understanding of how certs work I didn't have much awareness of VPN protocols or terminology so I had to abuse google pretty thoroughly.
It took about a day to do and I had to watch logs from server and client to figure it out, but it was interesting. I'm still pleased with the results and would recommend the product.
One of the reasons ipsec is tricky to understand is it doesn't create virtual interfaces like most other vpn systems on linux. With something like openvpn you can run tcpdump on eth0 / tun0 to figure out what is going on. With ipsec there's no 'ipsec0' interface and the way it works is a little more 'magic'.
During the past holidays, at my parent’s, I set up some infrastructure to allow remote management of some network equipment and computers. I used to employ OpenVPN for this, but I decided to give IPsec a try. Since I have been learning CentOS, initially I went with RedHat’s suggested option: Libreswan.
I tried and tried, yet couldn’t get it to work. Documentation surely was lacking for Libreswan. But then I found Strongswan, and after a few more attempts I managed to set a tunnel as I wanted it. The documentation is much more complete, and the examples were specially helpful.
I am baffled by the choice made by RedHat, to use Libreswan as their official IPsec implementation. It gave me a “beta” feel, while Strongswan seems more solid. Plus the difference regarding documentation is like night and day.
strongSwan is the best free and open source IPsec implementation available on Linux, (much better than libreswan...), good documentation, use cases and examples etc, good quality of code (less bugs - that's what we've found running it in production for 2+ years with 500+ instances deployed) actively developed and maintained by a group of passionate developers that knows the stuff well.
Personally I've been using strongSwan since its 5.0.x for remote access - protect privacy and fight censorship (yes, originally from China where the infamous GFW is deployed...). The native strongSwan client for Android is also a killer feature worth mentioning, RSA authentication with X509 certificates works flawlessly with 1 click ;-)
My company (pre-IPO startup) has been using strongSwan for 2+ years as site-to-site solution from AWS VPC to on-premises data centres (or other cloud virtual network), with 500+ instances deployed, track record has proved it reliable as long as it's properly configured (most outages were caused by AWS maintenance ;-) The only drawback is that strongSwan currently does NOT have a mature HA solution but it's shaping up (5.4.0 introduced IKEv2 redirect). We are currently building a custom HA solution (designed to work in VPC - provide similar redundancy to AWS VPN but a lot more flexible and controllable) using strongSwan (have to use route-based as syncing 2 policy based instances are too hard or impossible).
NOTE: I've seen people mentioned L2TP, it is obsolete. L2TP does NOT provide encryption or confidentiality to traffic passes through it. L2TP/IPsec encapsulates data twice at layer 2, it has pros and cons. See this (may be out-dated) -> https://www.bestvpn.com/blog/4147/pptp-vs-l2tp-vs-openvpn-vs...
IKEv{1,2} + IPsec (ESP) (tunnel mode) with PFS for both ike and esp is recommended configuration.
As mentioned in another comment: To properly install and configure strongSwan, following the tutorials available over the Internet is not enough, it requires good networking knowledge (NAT, iptables in particular), understanding of IPsec protocol suite (including IKE, AH, ESP), PKI, Linux skills and etc.
> NOTE: I've seen people mentioned L2TP, it is obsolete. L2TP does NOT provide encryption or confidentiality to traffic passes through it.
Would you clarify how it's obsolete, because it's doesn't follow from "L2TP does NOT provide encryption or confidentiality..."? AFAIK no one uses L2TP by itself, as there's no shortage of encapsulation protocols (GRE, AYIYA, vxlan, etc.) for other purposes. In practice L2TP/IPsec are always paired akin to TCP/IP, even though in theory you could do things like TCP/IPX or TCP/AppleTalk, or whatever. In the context of VPNs, L2TP/IPsec is "the protocol" even though they are two distinct pieces.
Sure it's not optimal, but for its intended purpose, establishing VPNs from roaming devices to intranets, the overhead hardly matters. IMO, what does matter is client device and network[0] compatibility, and L2TP/IPsec is hard to beat here. I wouldn't say that OpenVPN or other VPN solutions obsolete L2TP/IPsec in this aspect, either.
For (semi-)permanent site-to-site VPNs I agree just use IPsec.
[0] IIRC last time I chimed in on L2TP/IPsec you or someone else in the thread disputed that firewalls were generally not an issue for IPsec, contrary to my personal experience. Maybe I've just been extremely lucky, so I'll conceded this point.
Yup, it's the most actively maintained branch of all the XXXswan projects.
My experience has been that it's trivial to setup for site-to-site IPSec tunnels using PSK. It's literally install the package, copy a config file from the docs, start the service, done. I've been using it in scenarios like this for a while, works great even when the remote ends of the tunnel are something else (Cisco appliances, AWS VPN endpoints, etc).
I'm a little less sure how to implement it as a VPN endpoint for employees. There are two main issues here:
1. Having to support a variety of clients (Android, iOS, Mac OS X - perhaps also Windows and Linux)
2. Doing multifactor authentication in a way that works well
Especially when considering #1 and #2 together, it seems difficult to meet all demands. How to do multifactor in a way that works with many different clients? I don't much care what the "factors" are as long as they are "multi". E.g. certificate + individual password.
If I only had to support, say, user/pass authentication, I think that would be somewhat easily doable.
It is indeed a bit of a pain to set up properly, but it can be done, I have a droplet running it 24/7 and have no problems connecting to it from Apple devices. Here are some helpful guides for setting up:
When I was looking to replace my OpenVPN server for a cloud based VPN one thing I wanted was to use the OS native VPN solution. Everything pointed me to L2TP/IPSec, I am wondering why I would choose IKEv2 over that.
First off, IKEv2 is IPSec. IPSec tunnels are either IKEv1 or IKEv2.
The advantages:
* It has a streamlined/faster key negotiation protocol. IKEv2 tunnels can be established in a fraction of the time it takes for IKEv1 negotiation, especially when negotiating multiple SAs.
* More robust integrity algorithms which can detect and re-establish a tunnel faster.
* It supports EAP, so in client/server mode (vs. tunnel mode) you can attach it to an AAA server to assign IP addresses and do user authentication, making L2TP and shared secrets unnecessary. (Note that when using IKEv2 for IPSec tunnels, one still must use either a shared secret or certificates for authentication.)
StrongSwan is a real powerhorse, even though a bit of a b*tch to configure to work out-of-the-box on most platforms. The documentation is scarce and the wiki was a bit out of date IIRC.
I'm using it on my VPS, with my Mac as a client to bypass the UK big brother, and on Android to bypass tethering blocks (in conjunction with the Tether app)
For site-to-site PSK tunnels it's really trivial to setup. Just install the package, copy/paste a config from the docs, add the PSK on both sides, and start the service. Wham, bam, thank you ma'am, you're done.
You really don't have to worry about all this if you're asking.
Most people use VPN for security purposes. Now, when I mention security, there's various kinds. It can vary from hiding from state-attackers, to not wanting to be surveilled, to just torrenting stuff to avoiding a nasty letter from your ISP.
If you have nothing to worry about in the last paragraph, then the other case is organisational policies or accessibility. Routing all client traffic through a companies server because some companies' internal servers only allow requests from whitelisted IPs and drop all other packets. Of course, as a consumer/employee this is not something you have to worry about but it is something for sysadmins, and/or the security person who makes decisions at a company. And looks like there are a few of those in this thread. Hence all these discussions.
If you want to get into using VPNs, I'd suggest getting a server online first, something from digital ocean, AWS or Gcloud. If you want something super cheap, I suggest OVH's VPS. And the best tutorials in my opinion are from Digital Ocean[1]. If you only know how to use Ubuntu, here's[2] what you want.
[+] [-] windexh8er|9 years ago|reply
While not a sales pitch, and in fact I don't think the product seems to have sold well anyway, it was very interesting to work with them on the test harness we built to validate correct IPsec operations, configuration, validation that data wasn't leaking outside of the SAs that were being provisioned, and performance via the translated policy. The relatable component was this was mainly done against StrongSwan implementations of the IKE daemon if I remember correctly (Linux, AIX and Solaris mainly). I wonder if any of those bits flowed back upstream or if the bolt-on aspect kept that from happening.
StrongSwan isn't complex if you are well versed in IPsec implementation as a whole. It's no more or less complicated than other implementation and is "better" than TLS in it's own right with regard to things that could go wrong. In static environments it's relatively painless once the learning curve is overcome.
That being said I feel like IPsec has a badge it will never get rid of and people discard it before attempting implementation at this point. Hopefully, as mentioned amongst the comments, things like WireGuard will mature and become more mainstream. I very much like the concept carry over that both IPsec and WireGuard can be silent actors within the network not giving away hosts as things like OpenVPN and SSH do. IPsec can, unfortunately, also be implemented to squawk at spurious connection attempts - but at least doesn't rely on the premise as much as things like OpenVPN and SSH do.
And for the record - you can tell someone who's dealt with IPsec extensively since they won't refer to it as IPSec. o_O Microsoft is notorious for getting it wrong.
[+] [-] dguido|9 years ago|reply
https://github.com/trailofbits/algo
It even generates Apple profiles to auto configure your iPhone!
[+] [-] thelittleone|9 years ago|reply
https://github.com/jlund/streisand
[+] [-] orf|9 years ago|reply
Was pretty painless.
1. https://github.com/hwdsl2/docker-ipsec-vpn-server
[+] [-] benmmurphy|9 years ago|reply
have a look at how 'rekeying' is done. look at the numerous bugs in strongswan issue tracker related to this. the whole protocol is a shit show and it is really surprising that anything actually works between different vendors.
[+] [-] newman314|9 years ago|reply
[+] [-] tamalsaha001|9 years ago|reply
You can see our work here: https://github.com/appscode/swanc
[+] [-] terrywang|9 years ago|reply
[+] [-] justinsaccount|9 years ago|reply
Any reason you didn't use weave?
[+] [-] falcolas|9 years ago|reply
OpenVPN worked just fine, but I could never make StrongSwan work at all. Which is a shame, I really wanted to have an easy-to-use VPN for my phone and so forth. Settled on OpenVPN, which worked well enough with the iOS clients.
[+] [-] terrywang|9 years ago|reply
To properly install and configure strongSwan, following the tutorials available over the Nnternet is not enough. One needs to have basic networking knowledge (NAT, iptables in particular), good understanding of IPsec protocol suite (including IKE, AH, ESP), PKI, Linux skills and etc.
This is a good reference but still needs the knowledge mentioned above to get it to work: https://raymii.org/s/tutorials/IPSEC_vpn_with_Ubuntu_16.04.h...
[+] [-] spaceboy|9 years ago|reply
I feel your pain. I remember trying to install DNSCrypt[1] on Linux and failing miserably. I was convinced it would work if only I found the right solution online, or if only the right amount of caffeine was in my bloodstream, or if by sheer effort of will I could get it working, but I still failed. I partially got it installed, error messages galore in my terminal, and all my /paths/ were wrong. It was a humbling experience. I quickly uninstalled it as I don't want partially working, broken soft running on my machine.
I guess for this situation a decent OpenVPN client would be ideal like Viscosity[2]
[1] https://www.dnscrypt.org/
[2] https://www.sparklabs.com/viscosity/
[+] [-] sedachv|9 years ago|reply
[+] [-] baby|9 years ago|reply
what are the incentives to continue using IPsec or Strongswan?
[+] [-] drdaeman|9 years ago|reply
[+] [-] danesparza|9 years ago|reply
[+] [-] rkeene2|9 years ago|reply
I've setup StrongSWAN using smartcards almost 15 years ago, at the time it was the only open source IPSec client that supported it. It was relatively easy to get going (the server was a Cisco VPN appliance, which I managed and it was relatively easy to extract the relevant IKE profiles).
[+] [-] JustSomeNobody|9 years ago|reply
Oh, and where is Wireguard supported out of the box like IPsec is?
[+] [-] cthalupa|9 years ago|reply
[+] [-] binalpatel|9 years ago|reply
[+] [-] danudey|9 years ago|reply
[+] [-] equalunique|9 years ago|reply
[+] [-] softwarelimits|9 years ago|reply
[+] [-] kchoudhu|9 years ago|reply
I was thrilled when FreeBSD added IPSEC support in 11-RELEASE, but was less excited to learn that IPSEC_NAT_T wasn't compiled in, making it impossible to use strongswan. Oh well, maybe in 11.1 :)
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] ratherbefuddled|9 years ago|reply
The process was complex and there are things I still don't understand but it does work and the documentation and examples are quite comprehensive. The only issue I had with them was they assume a fair amount of familiarity with subjects that I didn't have. I'm mainly a serverside developer not a network admin, and whilst I have a vague understanding of how certs work I didn't have much awareness of VPN protocols or terminology so I had to abuse google pretty thoroughly.
It took about a day to do and I had to watch logs from server and client to figure it out, but it was interesting. I'm still pleased with the results and would recommend the product.
[+] [-] Nux|9 years ago|reply
It's an open source implementation of the Cisco AnyConnect SSL vpn, works great and it's compatible with the AnyConnect clients.
[+] [-] tehno|9 years ago|reply
[0] https://github.com/ftao/vpn-deploy-playbook/tree/master/role...
[+] [-] justinsaccount|9 years ago|reply
[+] [-] pYQAJ6Zm|9 years ago|reply
I tried and tried, yet couldn’t get it to work. Documentation surely was lacking for Libreswan. But then I found Strongswan, and after a few more attempts I managed to set a tunnel as I wanted it. The documentation is much more complete, and the examples were specially helpful.
I am baffled by the choice made by RedHat, to use Libreswan as their official IPsec implementation. It gave me a “beta” feel, while Strongswan seems more solid. Plus the difference regarding documentation is like night and day.
[+] [-] terrywang|9 years ago|reply
Personally I've been using strongSwan since its 5.0.x for remote access - protect privacy and fight censorship (yes, originally from China where the infamous GFW is deployed...). The native strongSwan client for Android is also a killer feature worth mentioning, RSA authentication with X509 certificates works flawlessly with 1 click ;-)
My company (pre-IPO startup) has been using strongSwan for 2+ years as site-to-site solution from AWS VPC to on-premises data centres (or other cloud virtual network), with 500+ instances deployed, track record has proved it reliable as long as it's properly configured (most outages were caused by AWS maintenance ;-) The only drawback is that strongSwan currently does NOT have a mature HA solution but it's shaping up (5.4.0 introduced IKEv2 redirect). We are currently building a custom HA solution (designed to work in VPC - provide similar redundancy to AWS VPN but a lot more flexible and controllable) using strongSwan (have to use route-based as syncing 2 policy based instances are too hard or impossible).
NOTE: I've seen people mentioned L2TP, it is obsolete. L2TP does NOT provide encryption or confidentiality to traffic passes through it. L2TP/IPsec encapsulates data twice at layer 2, it has pros and cons. See this (may be out-dated) -> https://www.bestvpn.com/blog/4147/pptp-vs-l2tp-vs-openvpn-vs...
IKEv{1,2} + IPsec (ESP) (tunnel mode) with PFS for both ike and esp is recommended configuration.
As mentioned in another comment: To properly install and configure strongSwan, following the tutorials available over the Internet is not enough, it requires good networking knowledge (NAT, iptables in particular), understanding of IPsec protocol suite (including IKE, AH, ESP), PKI, Linux skills and etc.
A good reference to start with: https://raymii.org/s/tutorials/IPSEC_vpn_with_Ubuntu_16.04.h...
[+] [-] RJIb8RBYxzAMX9u|9 years ago|reply
Would you clarify how it's obsolete, because it's doesn't follow from "L2TP does NOT provide encryption or confidentiality..."? AFAIK no one uses L2TP by itself, as there's no shortage of encapsulation protocols (GRE, AYIYA, vxlan, etc.) for other purposes. In practice L2TP/IPsec are always paired akin to TCP/IP, even though in theory you could do things like TCP/IPX or TCP/AppleTalk, or whatever. In the context of VPNs, L2TP/IPsec is "the protocol" even though they are two distinct pieces.
> L2TP/IPsec encapsulates data twice at layer 2, it has pros and cons. See this (may be out-dated) -> https://www.bestvpn.com/blog/4147/pptp-vs-l2tp-vs-openvpn-vs....
Sure it's not optimal, but for its intended purpose, establishing VPNs from roaming devices to intranets, the overhead hardly matters. IMO, what does matter is client device and network[0] compatibility, and L2TP/IPsec is hard to beat here. I wouldn't say that OpenVPN or other VPN solutions obsolete L2TP/IPsec in this aspect, either.
For (semi-)permanent site-to-site VPNs I agree just use IPsec.
[0] IIRC last time I chimed in on L2TP/IPsec you or someone else in the thread disputed that firewalls were generally not an issue for IPsec, contrary to my personal experience. Maybe I've just been extremely lucky, so I'll conceded this point.
[+] [-] Florin_Andrei|9 years ago|reply
My experience has been that it's trivial to setup for site-to-site IPSec tunnels using PSK. It's literally install the package, copy a config file from the docs, start the service, done. I've been using it in scenarios like this for a while, works great even when the remote ends of the tunnel are something else (Cisco appliances, AWS VPN endpoints, etc).
I'm a little less sure how to implement it as a VPN endpoint for employees. There are two main issues here:
1. Having to support a variety of clients (Android, iOS, Mac OS X - perhaps also Windows and Linux)
2. Doing multifactor authentication in a way that works well
Especially when considering #1 and #2 together, it seems difficult to meet all demands. How to do multifactor in a way that works with many different clients? I don't much care what the "factors" are as long as they are "multi". E.g. certificate + individual password.
If I only had to support, say, user/pass authentication, I think that would be somewhat easily doable.
Any clues?
[+] [-] shawkinaw|9 years ago|reply
https://www.zeitgeist.se/2013/11/22/strongswan-howto-create-...
http://www.jfcarter.net/~jimc/documents/strongswan-1308.html
[+] [-] ratherbefuddled|9 years ago|reply
[+] [-] dkhenry|9 years ago|reply
[+] [-] teilo|9 years ago|reply
The advantages:
* It has a streamlined/faster key negotiation protocol. IKEv2 tunnels can be established in a fraction of the time it takes for IKEv1 negotiation, especially when negotiating multiple SAs.
* More robust integrity algorithms which can detect and re-establish a tunnel faster.
* It supports EAP, so in client/server mode (vs. tunnel mode) you can attach it to an AAA server to assign IP addresses and do user authentication, making L2TP and shared secrets unnecessary. (Note that when using IKEv2 for IPSec tunnels, one still must use either a shared secret or certificates for authentication.)
[+] [-] fulafel|9 years ago|reply
(Technically you can also skip IKE and manually configure thesymmetric keys and parameters, using eg setkey from Linux ipsec-tools)
[+] [-] cthalupa|9 years ago|reply
[+] [-] laura2013|9 years ago|reply
[+] [-] fulafel|9 years ago|reply
[+] [-] 1_player|9 years ago|reply
I'm using it on my VPS, with my Mac as a client to bypass the UK big brother, and on Android to bypass tethering blocks (in conjunction with the Tether app)
[+] [-] Florin_Andrei|9 years ago|reply
[+] [-] klinquist|9 years ago|reply
[+] [-] post_break|9 years ago|reply
[+] [-] more_corn|9 years ago|reply
[+] [-] mwj|9 years ago|reply
[+] [-] peterposter|9 years ago|reply
e: Everybody says that using a VPN is a "good thing" but I honestly can't find a use for one in my day-to-day.
[+] [-] ktta|9 years ago|reply
Most people use VPN for security purposes. Now, when I mention security, there's various kinds. It can vary from hiding from state-attackers, to not wanting to be surveilled, to just torrenting stuff to avoiding a nasty letter from your ISP.
If you have nothing to worry about in the last paragraph, then the other case is organisational policies or accessibility. Routing all client traffic through a companies server because some companies' internal servers only allow requests from whitelisted IPs and drop all other packets. Of course, as a consumer/employee this is not something you have to worry about but it is something for sysadmins, and/or the security person who makes decisions at a company. And looks like there are a few of those in this thread. Hence all these discussions.
If you want to get into using VPNs, I'd suggest getting a server online first, something from digital ocean, AWS or Gcloud. If you want something super cheap, I suggest OVH's VPS. And the best tutorials in my opinion are from Digital Ocean[1]. If you only know how to use Ubuntu, here's[2] what you want.
[1]:https://www.digitalocean.com/community/tags/vpn?type=tutoria...
[2]: https://www.digitalocean.com/community/tutorials/how-to-set-...