10:52 a.m.
Hello Fedora hackers,
Since CIPE's removal from Fedora Core, there is a noticeable void that
still needs to be filled. I'd like to raise the issue here and spark a
discussion in the hope that we can find consensus on one or more pieces
of VPN software to include in Fedora Core 3.
There seem to be two general approaches to VPNs, each with their own
advantages and disadvantages: kernel space, and user space. I feel the
only kernel solutions worth considering are those which implement IPsec.
There exist several packages implementing VPN solutions in userspace,
such as vtun, tinc, and OpenVPN.
I have been using and reading about OpenVPN (http://openvpn.sf.net). It
is intuitive, well designed [1], and has excellent documentation. It is
released under the GPL, with a special exception clause to allow linking
with OpenSSL. OpenVPN is quality software, and we would be remiss not to
consider it for inclusion in FC3.
CIPE, vtun, and tinc, at least, have known and published flaws. Last
year Peter Gutmann wrote a paper detailing a number of problems with
these packages [2]. While Gutmann did not review OpenVPN in depth, he
did have this to say about it:
The key management step (that is, how to get from the SSL
control channel to the data channel) is documented only in the
source code, which I don't feel like reverse-engineering, but a
quick look through it indicates that the author knows what he's
doing.
I've done some googling and unfortunately I can't find a thorough,
independent audit of OpenVPN's design. However, I've also not been able
to find much in way of vulnerabilities, so it appears to have a good
track record. This, in combination with Gutmann's remarks in his paper,
as well as my own understanding of its design, gives me a reasonable
amount of confidence in OpenVPN. (Vastly more than CIPE, at least,
which was included in RHL in the past.)
OpenVPN is released for most unices (including OS X), as well as Windows
2000/XP. It relies on the kernel only for the tun/tap device. I have
toyed with other VPN software (notable CIPE, vtun, and freeswan), and
OpenVPN was the only one that Just Worked, and worked intuitively.
I think the other main contender for VPN software in Fedora Core would
be Openswan. OpenVPN is portable, comfortable (being in userspace),
flexible, and easy, but Openswan implements IPsec which is (mostly)
standardized across vendors, and that's certainly a strong selling
point, in spite of its complexity.
I don't know much about Openswan, but I do feel that there is room for
both an IPsec and user space VPN solution in FC.
So, let the discussions begin!
Cheers,
Jason.
[1] I am not a cryptographer, and so my opinion of OpenVPN's
design is meaningless in practice.
[2] http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt
12:25 p.m.
On Fri, May 21, 2004 at 11:52:09AM -0400, Jason Tackaberry wrote:
I'd like to raise the issue here and spark a discussion in the
hope
that we can find consensus on one or more pieces of VPN software to
include in Fedora Core 3.
Well, FC2 includes ipsec-tools, so I wouldn't say it includes no VPN
software.
I have been using and reading about OpenVPN (http://openvpn.sf.net).
It
is intuitive, well designed [1], and has excellent documentation. It is
released under the GPL, with a special exception clause to allow linking
with OpenSSL. OpenVPN is quality software, and we would be remiss not to
consider it for inclusion in FC3.
There's a OpenVPN package in fedora.us QA:
https://bugzilla.fedora.us/show_bug.cgi?id=1531
(Which reminds me, I never did submit a couple of minor fixes I made.
Oops.)
OpenVPN is released for most unices (including OS X), as well as
Windows
2000/XP. It relies on the kernel only for the tun/tap device. I have
toyed with other VPN software (notable CIPE, vtun, and freeswan), and
OpenVPN was the only one that Just Worked, and worked intuitively.
I can second that. I've used it Linux-to-Linux and Windows-to-Linux
and it Just Worked. It has also Just Worked behind a bunch of random
firewalls.
I think the other main contender for VPN software in Fedora Core
would
be Openswan. OpenVPN is portable, comfortable (being in userspace),
flexible, and easy, but Openswan implements IPsec which is (mostly)
standardized across vendors, and that's certainly a strong selling
point, in spite of its complexity.
Like I said, FC2 can already to IPsec. Regardless, I have also been
working on an openswan package for fedora.us:
https://bugzilla.fedora.us/show_bug.cgi?id=1271
It still needs work, and I haven't even thought about getting it
working with the built-in 2.6 IPsec stuff yet.
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
12:45 p.m.
On Fri, 21 May 2004, Jason Tackaberry wrote:
I've done some googling and unfortunately I can't find a
thorough,
independent audit of OpenVPN's design. However, I've also not been able
to find much in way of vulnerabilities, so it appears to have a good
track record. This, in combination with Gutmann's remarks in his paper,
as well as my own understanding of its design, gives me a reasonable
amount of confidence in OpenVPN. (Vastly more than CIPE, at least,
which was included in RHL in the past.)
Yes, Gutmann's comments in general are very positive about OpenVPN.
I don't know much about Openswan, but I do feel that there is
room for
both an IPsec and user space VPN solution in FC.
Openswan is likely to be very useful to folk who need to use IPSec with
NAT-T, xauth etc.
- James
--
James Morris
<jmorris(a)redhat.com>
2:04 p.m.
On Fri, 2004-05-21 at 17:52, Jason Tackaberry wrote:
There seem to be two general approaches to VPNs, each with their own
advantages and disadvantages: kernel space, and user space. I feel the
only kernel solutions worth considering are those which implement IPsec.
There exist several packages implementing VPN solutions in userspace,
such as vtun, tinc, and OpenVPN.
I would stick with industry-standard technologies, like IPSec, as much
as possible. I have used IPSec in tunnel mode to setup VPN tunnels
between several branch offices.
--- BEGIN ADVICE ---
However, I must say there are some problems with automatic keying and
2.6 kernels regarding the use of ISAKMP/IKE. The problem is that
settings an SPD between both tunnel end-points causes the first packet
between any of them to start negotiating the Security Association. But
the kernel, instead of queueing the packet that triggered the ISAKMP/IKE
exchange (in order to set up the SA), discards it and returns -EGAIN
error to the userspace caller which, in turn, translates into "Resource
temporarily unavailable" for user space programs.
This happened to me when using "racoon" to manage an automatically keyed
SA, based on X.509 certificates. Doing a ping to force the ISAKMP/IKE
exchange, and to set up the SA, caused the first ping packet to fail
with "Resource temporarily unavailable". Once the SA had been set up, no
more packets were discared.
--- END ADVICE ---
Don't know if this behavior is applicable to 2.4 kernels, Free/SWAN or
Open/SWAP IPSec stacks.
2:22 p.m.
On Fri, 21 May 2004, Felipe Alfaro Solana wrote:
However, I must say there are some problems with automatic keying
and
2.6 kernels regarding the use of ISAKMP/IKE. The problem is that
settings an SPD between both tunnel end-points causes the first packet
between any of them to start negotiating the Security Association. But
the kernel, instead of queueing the packet that triggered the ISAKMP/IKE
exchange (in order to set up the SA), discards it and returns -EGAIN
error to the userspace caller which, in turn, translates into "Resource
temporarily unavailable" for user space programs.
This is a known issue which needs to be fixed in the upstream kernel.
- James
--
James Morris
<jmorris(a)redhat.com>
3:32 p.m.
Felipe Alfaro Solana <felipe_alfaro(a)linuxmail.org> said:
On Fri, 2004-05-21 at 17:52, Jason Tackaberry wrote:
> There seem to be two general approaches to VPNs, each with their own
> advantages and disadvantages: kernel space, and user space. I feel the
> only kernel solutions worth considering are those which implement IPsec.
> There exist several packages implementing VPN solutions in userspace,
> such as vtun, tinc, and OpenVPN.
I would stick with industry-standard technologies, like IPSec, as much
as possible. I have used IPSec in tunnel mode to setup VPN tunnels
between several branch offices.
While IPSec tends to work fine for static VPNs in cases where you have full
control over all firewalls, there are cases that come up where IPSec cannot be
used, such as
* Mobile (i.e. road-warrior) usage. Road warriors running a VPN client on a
laptop may need to securely connect from untrusted networks such as client
sites, internet cafes, LANs behind NAT, etc., where the VPN user does not have
control over the firewall policy on the local network. A user-space VPN such
as OpenVPN can connect via TCP, UDP, HTTP, socks, etc, and can do it over NAT.
* VPNs between machines which don't have a static IP address, such as cable
modem or DSL clients which have a DHCP assigned address. OpenVPN has the
ability to "follow" its peer if it changes its address due to a DHCP
reassignment.
* IPSec is tightly coupled with IP and therefore is principally suited for
securing IP-based routed networks. However an extremely common VPN
application is in securing ethernet 202.3 bridges. User space VPNs which
utilize TUN or TAP type virtual network interfaces can tunnel or bridge
arbitrary application or transport protocols transparently.
As far as the issue of industry standarization is concerned, there is not yet
an RFC to standardize SSL/TLS VPN usage. This is certainly a valid issue,
though movement is occuring toward drafting a standard. A key point to
recognize is that even though SSL/TLS VPN protocols have not been canonized by
RFC, the security technologies being utilized HAVE been. OpenVPN for example
uses SSL/TLS for authentication and key exchange, and IPSec's ESP for datagram
security.
The other issue concerning standardization is that VPNs with extreme
cross-platform portability have less of a need for multi-vendor
interoperability simply because they can be run on almost any platform.
James
4:57 p.m.
On Fri, 2004-05-21 at 22:32, James Yonan wrote:
>
> I would stick with industry-standard technologies, like IPSec, as much
> as possible. I have used IPSec in tunnel mode to setup VPN tunnels
> between several branch offices.
While IPSec tends to work fine for static VPNs in cases where you have full
control over all firewalls, there are cases that come up where IPSec cannot be
used, such as
* Mobile (i.e. road-warrior) usage. Road warriors running a VPN client on a
laptop may need to securely connect from untrusted networks such as client
sites, internet cafes, LANs behind NAT, etc., where the VPN user does not have
control over the firewall policy on the local network. A user-space VPN such
as OpenVPN can connect via TCP, UDP, HTTP, socks, etc, and can do it over NAT.
I think this can/will be solved by implementing Mobile IPv4 or Mobile
IPv6 and using Home Agents that are able to proxy the mobile host and
thus masquerade the fact that it has changed its network attachment and,
with high probability, its IP address. In fact, I think there are Mobile
IPSec extensions currently in draft status.
However, it's probably more difficult to implement a solution based on
Mobile IPSec at the moment than using a solution like OpenVPN.
* VPNs between machines which don't have a static IP address,
such as cable
modem or DSL clients which have a DHCP assigned address. OpenVPN has the
ability to "follow" its peer if it changes its address due to a DHCP
reassignment.
I think the previous paragraph still applies here.
* IPSec is tightly coupled with IP and therefore is principally
suited for
securing IP-based routed networks. However an extremely common VPN
application is in securing ethernet 202.3 bridges. User space VPNs which
utilize TUN or TAP type virtual network interfaces can tunnel or bridge
arbitrary application or transport protocols transparently.
I agree.
As far as the issue of industry standarization is concerned, there is
not yet
an RFC to standardize SSL/TLS VPN usage. This is certainly a valid issue,
though movement is occuring toward drafting a standard.
There are several drafts related to VPN technologies, like MPLS VPNs,
IPSec + L2TP for end-user and machine authentication, and SSL/TLS/SSH
tunneling. They will take time to reach the standard status, but I think
this will happen sooner or later.
6:08 a.m.
On 2004-05-21 (Friday) 22:04, Felipe Alfaro Solana wrote:
On Fri, 2004-05-21 at 17:52, Jason Tackaberry wrote:
> There seem to be two general approaches to VPNs, each with their own
> advantages and disadvantages: kernel space, and user space. I feel the
> only kernel solutions worth considering are those which implement IPsec.
> There exist several packages implementing VPN solutions in userspace,
> such as vtun, tinc, and OpenVPN.
I would stick with industry-standard technologies, like IPSec, as much
as possible. I have used IPSec in tunnel mode to setup VPN tunnels
between several branch offices.
In my case, here in Bulgaria, I can't - we have clients with dynamic IP addresses
and behind NAT. I use OpenVPN last two months without any problem (except I had to
add alternative ports 'cause in some places 5000/TCP was filtered). I would love to
see OpenVPN and XCA (both available for linux and windows) in Fedora (maybe FC3).
With FC2 I'll surely add IPSec too, but I prefer having them both up and running just
in case (OpenVPN can connect even when you have http proxy only)...
...
--
Regards,
Doncho N. Gunchev Registered Linux User #291323 at counter.li.org
GPG-Key-ID: 1024D/DA454F79
Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79
7:59 a.m.
Felipe Alfaro Solana wrote:
On Fri, 2004-05-21 at 17:52, Jason Tackaberry wrote:
>There seem to be two general approaches to VPNs, each with their own
>advantages and disadvantages: kernel space, and user space. I feel the
>only kernel solutions worth considering are those which implement IPsec.
>There exist several packages implementing VPN solutions in userspace,
>such as vtun, tinc, and OpenVPN.
I would stick with industry-standard technologies, like IPSec, as much
as possible. I have used IPSec in tunnel mode to setup VPN tunnels
between several branch offices.
--- BEGIN ADVICE ---
However, I must say there are some problems with automatic keying and
2.6 kernels regarding the use of ISAKMP/IKE. The problem is that
settings an SPD between both tunnel end-points causes the first packet
between any of them to start negotiating the Security Association. But
the kernel, instead of queueing the packet that triggered the ISAKMP/IKE
exchange (in order to set up the SA), discards it and returns -EGAIN
error to the userspace caller which, in turn, translates into "Resource
temporarily unavailable" for user space programs.
This happened to me when using "racoon" to manage an automatically keyed
SA, based on X.509 certificates. Doing a ping to force the ISAKMP/IKE
exchange, and to set up the SA, caused the first ping packet to fail
with "Resource temporarily unavailable". Once the SA had been set up, no
more packets were discared.
--- END ADVICE ---
Don't know if this behavior is applicable to 2.4 kernels, Free/SWAN or
Open/SWAP IPSec stacks.
we've about 80 vpn endpoints. at the begining we try to use freeswan and
ipsec, than racoon, but after a few mounts we give it up. they
(currently) all has such bugs and missing features that are essential in
a real enviroment. may be ipsec is the future, but still not know. at
the sam time openvpn has all the required features and even more!
reliable, fast and easy to install and manage! I already ask it for last
year but:
http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00927.html
--
Levente "Si vis pacem para bellum!"
9:06 p.m.
On 22/05/2004, at 1:52 AM, Jason Tackaberry wrote:
Since CIPE's removal from Fedora Core, there is a noticeable void
that
still needs to be filled. I'd like to raise the issue here and spark a
discussion in the hope that we can find consensus on one or more pieces
of VPN software to include in Fedora Core 3.
I know this will leave a bad taste in peoples mouths, but from a
practicality point of view the Microsoft VPN (MPPE and friends, iirc)
is implemented by a kernel patch in ppp CVS (providing the ppp_mppe
module). I've got that patch in my kernel at the moment and it works
well. The great thing is that it works with everything - Linux, Mac OS
X and Windows, and works over a masquerade for the client. I think
these two points are important (particularly useful for RHEL customers,
I would have thought) - range of client compatibility, and the client
working over a masquerade.
The patch has been around for a fair while (I've had it patched in for
about 6 months now, god knows how long it's been around before that). I
haven't bothered looking into why Linus hasn't merged it, since crypto
is now in the kernel. Maybe patent issues in the US?
Nathan.
11:10 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 22 May 2004 19:06, Nathan Robertson wrote:
I know this will leave a bad taste in peoples mouths, but from a
practicality point of view the Microsoft VPN (MPPE and friends, iirc)
is implemented by a kernel patch in ppp CVS (providing the ppp_mppe
module). I've got that patch in my kernel at the moment and it works
well. The great thing is that it works with everything - Linux, Mac
OS X and Windows, and works over a masquerade for the client. I think
these two points are important (particularly useful for RHEL
customers, I would have thought) - range of client compatibility, and
the client working over a masquerade.
The patch has been around for a fair while (I've had it patched in
for about 6 months now, god knows how long it's been around before
that). I haven't bothered looking into why Linus hasn't merged it,
since crypto is now in the kernel. Maybe patent issues in the US?
I do believe the biggest thing is that the module taints your kernel.
Non GPL compliant I do believe.
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAsCQi4v2HLvE71NURAvt5AKCV95mNps8qJbMdiF3jWilv//81uACgoQag
uDKtgNWas3kAW4a5N7VkbbE=
=kXZF
-----END PGP SIGNATURE-----
3:53 a.m.
On 23/05/2004, at 2:10 PM, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 22 May 2004 19:06, Nathan Robertson wrote:
> I know this will leave a bad taste in peoples mouths, but from a
> practicality point of view the Microsoft VPN (MPPE and friends, iirc)
> is implemented by a kernel patch in ppp CVS (providing the ppp_mppe
> module). [...]
I do believe the biggest thing is that the module taints your kernel.
Non GPL compliant I do believe.
cobra:~# lsmod
Module Size Used by Tainted: P
[...]
ppp_mppe 12320 0 (unused)
[...]
Damn. It's tainted, yes. Never noticed. I'm looking at the patch and
don't see any nasty license issues - just a lack of a explicit GPL
compatible flag set. It consists of:
- a patch to the current ppp (derived work, hence GPL).
- sha1.[ch] - in comments at the top -- "100% Public Domain"
- ppp_mppe_compress.c - "Permission to use, copy, modify, and
distribute this software and its documentation is hereby granted,
provided that the above copyright notice appears in all copies."
So in my view it's actually a mix between GPL, public domain and a BSD
style license. Looks GPL compatible to me. Just needs to be noted as
explicitly so, so it doesn't taint the kernel. Am I right?
Having said that, I haven't tested it with 2.6 kernel, and the headers
say 2.2 and 2.4 (presumably because it hasn't been tested).
Nathan.
4:43 a.m.
On 23/05/2004, at 6:53 PM, Nathan Robertson wrote:
On 23/05/2004, at 2:10 PM, Jesse Keating wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 22 May 2004 19:06, Nathan Robertson wrote:
>> I know this will leave a bad taste in peoples mouths, but from a
>> practicality point of view the Microsoft VPN (MPPE and friends, iirc)
>> is implemented by a kernel patch in ppp CVS (providing the ppp_mppe
>> module). [...]
>
> I do believe the biggest thing is that the module taints your kernel.
> Non GPL compliant I do believe.
cobra:~# lsmod
Module Size Used by Tainted: P
[...]
ppp_mppe 12320 0 (unused)
[...]
Damn. It's tainted, yes. Never noticed. I'm looking at the patch and
don't see any nasty license issues - just a lack of a explicit GPL
compatible flag set. It consists of:
- a patch to the current ppp (derived work, hence GPL).
- sha1.[ch] - in comments at the top -- "100% Public Domain"
- ppp_mppe_compress.c - "Permission to use, copy, modify, and
distribute this software and its documentation is hereby granted,
provided that the above copyright notice appears in all copies."
So in my view it's actually a mix between GPL, public domain and a BSD
style license. Looks GPL compatible to me. Just needs to be noted as
explicitly so, so it doesn't taint the kernel. Am I right?
Having said that, I haven't tested it with 2.6 kernel, and the headers
say 2.2 and 2.4 (presumably because it hasn't been tested).
PS. Source is in a cvs-web as well --
http://cvs.samba.org/cgi-bin/cvsweb/ppp/linux/mppe
Nathan.
5:50 a.m.
On Sun, May 23, 2004 at 12:06:21PM +1000, Nathan Robertson wrote:
The patch has been around for a fair while (I've had it patched
in for
about 6 months now, god knows how long it's been around before that). I
haven't bothered looking into why Linus hasn't merged it, since crypto
It may just be stuff that never got in due to the crypto thing originally.
Linus is however not omniescent so you could send him a copy and ask.
Probably Paul Mackerras is the right man to ask in fact as its ppp stuff
2:56 p.m.
On Fri, 2004-05-21 at 08:52, Jason Tackaberry wrote:
I think the other main contender for VPN software in Fedora Core would
be Openswan. OpenVPN is portable, comfortable (being in userspace),
flexible, and easy, but Openswan implements IPsec which is (mostly)
standardized across vendors, and that's certainly a strong selling
point, in spite of its complexity.
Openswan is good to keep around, just in case you need to talk to IPSec
devices. But it's a pain in the butt; it's NAT-unfriendly, free and good
Windows clients are lacking, interoperability is problematic, etc.
I said, to hell with it, i installed OpenVPN and It Simply Works. It is
easy to setup (both server and clients), it does not care about NAT, the
Windows client is not a problem (it's the same software as the server),
interoperability is a breeze...
--
Florin Andrei
http://florin.myip.org/
2:32 a.m.
Florin Andrei wrote:
On Fri, 2004-05-21 at 08:52, Jason Tackaberry wrote:
>I think the other main contender for VPN software in Fedora Core would
>be Openswan. OpenVPN is portable, comfortable (being in userspace),
>flexible, and easy, but Openswan implements IPsec which is (mostly)
>standardized across vendors, and that's certainly a strong selling
>point, in spite of its complexity.
Openswan is good to keep around, just in case you need to talk to IPSec
devices. But it's a pain in the butt; it's NAT-unfriendly, free and good
Windows clients are lacking, interoperability is problematic, etc.
Eh?
OpenSWAN 2.1.2 works fine, interoperates fine with *most* IPSec clients,
including WinXP, and supports NAT-T (a.k.a. IPSec over UDP), so there
shouldn't be any problems.
I have been running OpenSWAN for a while now and the only problem I've
had with it is its somewhat limited handling of aggressive mode (which
FreeSWAN didn't implement due to its known security holes.)
-hpa
7294
days inactive
7304
days old
15 comments
12 participants
participants (12)
-
Alan Cox -
Doncho N. Gunchev -
Farkas Levente -
Felipe Alfaro Solana -
Florin Andrei -
H. Peter Anvin -
James Morris -
James Yonan -
Jason Tackaberry -
Jesse Keating -
Nathan Robertson -
Steven Pritchard