-----Original Message-----
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
My sense is that openvpn is the easiest to configure, the most robust and fault tolerant, as far as keeping connections up and reestablishing failed connections. The downside of openvpn is incompatibility with most mobile devices, not relevant if you are able to install openvpn clients. You can configure fixed IP addresses using either the ccd files or the client-connect script.
Based on other discussussions on the list my recollection is that IPSEC provides better performance if you need GigE or better data rates on your VPNs. My sense is that IPSEC may be more difficult to configure and less robust at keeping connections up, but this has probably improved in recent years.
The main advantage to pptp that I see is compatibility with mobile devices. A disadvantage of PPTP, as far as I know it cannot easily be tunneled through something like a linux firewall because it uses non-standard protocol packets (not TCP/UDP).
Both OPENVPN and IPSEC can easily be tunneled through most firewalls.
Though I have not researched this extensively, just based on watching list of security updates that get released for Centos, Fedora etc, It seems that OPENVPN has had very few security issues. I have definely seen a few for strongswan and openswan (both are IPSEC implementations). Again this is just gut feeling, not the result of any investigation. I do note though that OPENVPN runs easily in a chroot environment, just by enabling options in the config file. I'm not sure if openswan or strongswan can do this.
Nataraj
_______________________________________________
Hi,
If you don't use any fancy features, OpenVPN is rather easy to set up. Additional effort is needed with: -certificates -routing -smartcards
Exactly _the same troubles_ you will encounter with ipsec (though i have only used with strongswan)
If it is only master/slave configuration, openvpn will do, for a more complex topology (meshed) consider ipsec Will you be confronted with IPv6 in the (not so) near future? Forget OpenVPN, it is still beta there, while it has been implemented in strongswan for ages, and part of there standard test plan. Furthermore, openvpn is only compatible with openvpn, while using ipsec you might be able to connect to other boxes. If you can install software on both ends, openvpn is available for many platforms.
hw
______________________________________________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
On 25/11/10 14:12, J.Witvliet@mindef.nl wrote: [...snip...]
Will you be confronted with IPv6 in the (not so) near future? Forget OpenVPN, it is still beta there, while it has been implemented in strongswan for ages, and part of there standard test plan.
Okay, I'll admit up-front I'm biased, as I am involved in the OpenVPN project. But I can provide some info here.
IPv6 is currently in the development tree. I'm using it on my personal equipment now, using IPv6 over TUN interface between a OpenWRT router and a Linux "road warrior" client. I'm also looking for how to get this code base compiled for maemo5 as well. Early next year, I'm going to run this development code on a couple of production boxes as well.
Another developer (the guy who implemented the IPv6 support) is also using this IPv6 implementation in a bigger environment too.
We're currently in the end of the beta round for OpenVPN-2.2 and will release a RC version around Christmas. The full release will come sometime around January. That code base is without IPv6. (2.2 is basically a bigger bugfix release with a couple of new features)
The 2.3-beta round is scheduled sometime around February/March, with a release slated for late summer 2011. This release will include IPv6 support, both for transport (connect/listen/bind to IPv6 addresses) and payload (IPv6 over tun and tap via tunnel with IPv6 client configuration support).
http://thread.gmane.org/gmane.network.openvpn.devel/4221
But for early adopters ... the current development code is stable enough for daily usage without too much troubles. And we would like to see more people testing out this code.
https://community.openvpn.net/openvpn/wiki/TesterDocumentation
Furthermore, openvpn is only compatible with openvpn, while using ipsec you might be able to connect to other boxes.
That is mostly true, except for those vendors adding their own proprietary extensions to their ipsec implementations ... thus making it a vendor lock-in again.
"That's the wonderful thing about standards, everyone can have their own" - unknown
kind regards,
David Sommerseth
On 12/09/2010 10:30 AM, David Sommerseth wrote:
On 25/11/10 14:12, J.Witvliet@mindef.nl wrote: [...snip...]
Will you be confronted with IPv6 in the (not so) near future? Forget OpenVPN, it is still beta there, while it has been implemented in strongswan for ages, and part of there standard test plan.
Okay, I'll admit up-front I'm biased, as I am involved in the OpenVPN project. But I can provide some info here.
IPv6 is currently in the development tree. I'm using it on my personal equipment now, using IPv6 over TUN interface between a OpenWRT router and a Linux "road warrior" client. I'm also looking for how to get this code base compiled for maemo5 as well. Early next year, I'm going to run this development code on a couple of production boxes as well.
Another developer (the guy who implemented the IPv6 support) is also using this IPv6 implementation in a bigger environment too.
We're currently in the end of the beta round for OpenVPN-2.2 and will release a RC version around Christmas. The full release will come sometime around January. That code base is without IPv6. (2.2 is basically a bigger bugfix release with a couple of new features)
The 2.3-beta round is scheduled sometime around February/March, with a release slated for late summer 2011. This release will include IPv6 support, both for transport (connect/listen/bind to IPv6 addresses) and payload (IPv6 over tun and tap via tunnel with IPv6 client configuration support).
http://thread.gmane.org/gmane.network.openvpn.devel/4221
But for early adopters ... the current development code is stable enough for daily usage without too much troubles. And we would like to see more people testing out this code.
https://community.openvpn.net/openvpn/wiki/TesterDocumentation
Furthermore, openvpn is only compatible with openvpn, while using ipsec you might be able to connect to other boxes.
That is mostly true, except for those vendors adding their own proprietary extensions to their ipsec implementations ... thus making it a vendor lock-in again.
Hmm... We run ipsec, (using ipsec-tools on both Linux and FreeBSD), to Cisco, Juniper, NetScreen and many others without problem. What vendors are you talking about?
"That's the wonderful thing about standards, everyone can have their own" - unknownkind regards,
David Sommerseth
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 09/12/10 17:29, Steve Clark wrote:
On 12/09/2010 10:30 AM, David Sommerseth wrote:
On 25/11/10 14:12, J.Witvliet@mindef.nl wrote:
[...snip...]
Furthermore, openvpn is only compatible with openvpn, while using ipsec you might be able to connect to other boxes.
That is mostly true, except for those vendors adding their own proprietary extensions to their ipsec implementations ... thus making it a vendor lock-in again.
Hmm... We run ipsec, (using ipsec-tools on both Linux and FreeBSD), to Cisco, Juniper, NetScreen and many others without problem. What vendors are you talking about?
I don't have personal hand-on experiences with ipsec issues. However, I would expect things to work flawlessly as long as you don't enable vendor specific features, or if you enable compatible features.
http://www.veiligmobiel.com/IPsecCompatibility.htm
And I believe it will be even more differences if you try to use a "tunnelled" setup versus a "transport" setup, where the tunnelled mode will act more a like a SSL based VPN. If I have understood it correctly.
kind regards,
David Sommerseth
On 12/10/10 2:42 AM, David Sommerseth wrote:
On 09/12/10 17:29, Steve Clark wrote:
On 12/09/2010 10:30 AM, David Sommerseth wrote:
On 25/11/10 14:12, J.Witvliet@mindef.nl wrote:
[...snip...]
Furthermore, openvpn is only compatible with openvpn, while using ipsec you might be able to connect to other boxes.
That is mostly true, except for those vendors adding their own proprietary extensions to their ipsec implementations ... thus making it a vendor lock-in again.
Hmm... We run ipsec, (using ipsec-tools on both Linux and FreeBSD), to Cisco, Juniper, NetScreen and many others without problem. What vendors are you talking about?
I don't have personal hand-on experiences with ipsec issues. However, I would expect things to work flawlessly as long as you don't enable vendor specific features, or if you enable compatible features.
http://www.veiligmobiel.com/IPsecCompatibility.htm
And I believe it will be even more differences if you try to use a "tunnelled" setup versus a "transport" setup, where the tunnelled mode will act more a like a SSL based VPN. If I have understood it correctly.
On Ciscos I've always run GRE tunnels with only the GRE packets going through ipsec to get interfaces that can handle dynamic routing protocols, multicast, etc. Is there a way to get that kind of tunnel interface with ipsec alone?
On Dec 10, 2010, at 8:48 AM, Les Mikesell lesmikesell@gmail.com wrote:
On 12/10/10 2:42 AM, David Sommerseth wrote:
On 09/12/10 17:29, Steve Clark wrote:
On 12/09/2010 10:30 AM, David Sommerseth wrote:
On 25/11/10 14:12, J.Witvliet@mindef.nl wrote:
[...snip...]
Furthermore, openvpn is only compatible with openvpn, while using ipsec you might be able to connect to other boxes.
That is mostly true, except for those vendors adding their own proprietary extensions to their ipsec implementations ... thus making it a vendor lock-in again.
Hmm... We run ipsec, (using ipsec-tools on both Linux and FreeBSD), to Cisco, Juniper, NetScreen and many others without problem. What vendors are you talking about?
I don't have personal hand-on experiences with ipsec issues. However, I would expect things to work flawlessly as long as you don't enable vendor specific features, or if you enable compatible features.
http://www.veiligmobiel.com/IPsecCompatibility.htm
And I believe it will be even more differences if you try to use a "tunnelled" setup versus a "transport" setup, where the tunnelled mode will act more a like a SSL based VPN. If I have understood it correctly.
On Ciscos I've always run GRE tunnels with only the GRE packets going through ipsec to get interfaces that can handle dynamic routing protocols, multicast, etc. Is there a way to get that kind of tunnel interface with ipsec alone?
No, because IPSec tunnel mode works for a given routable network segment and multicast routing isn't handled.
I too use GRE tunnels over IPSec transport mode for site-to-site connectivity, so I can support OSPF and other multicast protocols.
For road warriors I use either l2tp (windows) or openvpn (Linux).
-Ross
-
David Sommerseth -
J.Witvliet＠mindef.nl -
Les Mikesell -
m.roth＠5-cent.us -
Ross Walker -
Steve Clark