Which VPN protocol is best?
-
I am fresh vpn user and basically I use pptp protocol for streaming. On last weekend with my friends, I was using Facebook from my smartphone. In a while my smartphone is going hacked and all data that already stored in my phone was too. At that time, I said "What the fuck is this" but one of my friend suggest me to don't use PPTP because it has zero level security.
Now, I have 3 different protocols option like l2tp, ikev2 and openvpn. Can anyone guide me which one is best for all purposes.
Thank You
-
@rootwilliamson OpenVPN is fast, secure and easier to configure than IPSec.
-
@KOM said in Which VPN protocol is best?:
OpenVPN is fast, secure and easier to configure than IPSec.
It however needs a client adding to the endpoints.
IKEv2 / IPsec is natively supported on a lot of endpoints.
-
@rootwilliamson said in Which VPN protocol is best?:
Now, I have 3 different protocols option like l2tp, ikev2 and openvpn. Can anyone guide me which one is best for all purposes.
And L2TP is mainly used in conjunction with IPSec with IKEv1 which - to my knowledge - adds the actual "security" part ... the cryptography
-
@NogBadTheBad said in Which VPN protocol is best?:
@KOM said in Which VPN protocol is best?:
OpenVPN is fast, secure and easier to configure than IPSec.
It however needs a client adding to the endpoints.
IKEv2 / IPsec is natively supported on a lot of endpoints.
Exactly! IKEv2 uses IPsec for encrypted the data but Openvpn uses SSL. In the meantime, I especially read about IPsec from different guides like
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-ipsec-vpn-overview.html
https://www.calyptix.com/research-2/ssl-vpn-and-ipsec-vpn-how-they-work/
https://www.purevpn.com/what-is-vpn/protocols/ipsecSo, what do you think IPsec is more secure than SSL.
-
@rootwilliamson said in Which VPN protocol is best?:
So, what do you think IPsec is more secure than SSL.
So I am not an crypot/math expert but apparently there is a consent that IPsec is secure when setup correctly https://www.schneier.com/academic/paperfiles/paper-ipsec.pdf
IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result. We are not alone in this opinion; from various discussions with the people involved, we learned that virtually nobody is satisfied with the process or the result. The development of IPsec seems to have been burdened by the committee process that it was forced to use, and it shows in the results. Even with all the serious critisisms that we have on IPsec, it is probably the best IP security protocol available at the moment. We have looked at other, functionally similar, protocols in the past (including PPTP [SM98, SM99]) in much the same manner as we have looked at IPsec. None of these protocols come anywhere near their target, but the others manage to miss the mark by a wider margin than IPsec. This difference is less significant from a security point of view; there are no points for getting security nearly right. From a marketing point of view, this is important. IPsec is the current “best practice,” no matter how badly that reflects on our ability to create a good security standard. Our main criticism of IPsec is its complexity. IPsec contains too many options and too much flexibility; there are often several ways of doing the same or similar things. This is a typical committee effect. Committees are notorious for adding features, options, and additional flexibility to satisfy various factions within the committee. As we all know, this additional complexity and bloat is seriously detrimental to a normal (functional) standard. However, it has a devastating effect on a security standard.
But the main problem is the complexity and that if one uses weak crypto, which might be likely due to its compexity, it could be crackable ?
So most people probably recommend OpenVPN due to this issue.
-
Thanks for good suggestion.
-
That PDF is dated 1999, things have moved on since then, i.e IKEv2 which was proposed in 2005 in RFC4306.
https://tools.ietf.org/html/rfc4306