vpn under linux
Hi all,
some of you can give me some input about the best way to set up a vpn under two Linux RH9 systems? I heared there are different solution (PPP and SSH, PPTP...) and I'd like to know your opinion about that. Thanks
Gianni
Quoted 5 lines · Gianni Pucciani
Hi all,
some of you can give me some input about the best way to set up a vpn under two Linux RH9 systems?
I heared there are different solution (PPP and SSH, PPTP...) and I'd like to know your opinion about that.
PPP is Point-to-Point Protocol, and has almost nothing to do with VPNs :)
SSH is Secure Shell, and at least it contains some encryption, but again, is almost nothing to do with VPNs (but more on that later).
PPTP is Pretty Poor Tunneling Protocol (oh, no, sorry, it's a Point to Point Tunneling Protocol...), and is the way Microsoft systems do VPN.
The "standard" way to do VPN (in other words, the method which is supported by most vendors, uses open standards, and also has the best security) is IPsec.
The usual way to do IPsec under Linux is to use FreeS/WAN under kernel 2.4, or the built-in IPsec under kernel 2.6.
I use FreeS/WAN, I like it, it works well with netfilter (once you've got used to the path the packets take at each end), and I'm happy with its 3DES/RSA security.
I said I'd mention more about SSH - that also uses good encryption and is therefore secure, and once you have an SSH connection between two machines, you can "tunnel" almost any network traffic you like between them, and it does work, although I wouldn't select this as a first choice for a VPN
because there's a lot more manual setting up involved. IPsec is more like a
network route - you just configure it, and let the two endpoint machines get on with negotiating the link, and then computers from whichever network ranges you've configured the VPN to support can connect to each other transparently through a nice secure tunnel across the Internet.
Hope this helps,
Regards,
Antony.
Signature · 4 lines
If at first you don't succeed, destroy all the evidence that you tried.
Please reply to the list;
please don't CC me.Quoted 12 lines · Antony Stone
Quoted 7 lines · Gianni Pucciani
Hi all,
some of you can give me some input about the best way to set up a vpn under two Linux RH9 systems?
I heared there are different solution (PPP and SSH, PPTP...) and I'd like to know your opinion about that.
Quoted 5 lines
PPP is Point-to-Point Protocol, and has almost nothing to do with VPNs :)
SSH is Secure Shell, and at least it contains some encryption, but again, is almost nothing to do with VPNs (but more on that later).
I thought that they could be used in conjuction to achieve vpn functionalities...
Quoted 9 lines
PPTP is Pretty Poor Tunneling Protocol (oh, no, sorry, it's a Point to Point Tunneling Protocol...), and is the way Microsoft systems do VPN.
The "standard" way to do VPN (in other words, the method which is supported by most vendors, uses open standards, and also has the best security) is IPsec.
The usual way to do IPsec under Linux is to use FreeS/WAN under kernel 2.4, or the built-in IPsec under kernel 2.6.
I use FreeS/WAN, I like it, it works well with netfilter (once you've got used to the path the packets take at each end), and I'm happy with its 3DES/RSA security.
Ok, I'll investigate this solution :-), thanks.
Quoted 5 lines
I said I'd mention more about SSH - that also uses good encryption and is therefore secure, and once you have an SSH connection between two machines, you can "tunnel" almost any network traffic you like between them, and it does work, although I wouldn't select this as a first choice for a VPN because there's a lot more manual setting up involved. IPsec is more like a network route - you just configure it, and let the two endpoint machines get on with negotiating the link, and then computers from whichever network ranges you've configured the VPN to support can connect to each other transparently through a nice secure tunnel across the Internet.
Hope this helps,
Sure it helps :-)
Thank you very much!
Gianni
Quoted 6 lines
Regards,
Antony.
Hi,
I forget one things, waht about the CIPE solution. I read that in the rh9 sec guide about VPN.
And then, I see this news: the FreeS/WAN project is no longer in active development, it could be a problem?
thanks
Quoted 34 lines · Antony Stone
Quoted 7 lines · Gianni Pucciani
Hi all,
some of you can give me some input about the best way to set up a vpn under two Linux RH9 systems?
I heared there are different solution (PPP and SSH, PPTP...) and I'd like to know your opinion about that.PPP is Point-to-Point Protocol, and has almost nothing to do with VPNs :)
SSH is Secure Shell, and at least it contains some encryption, but again, is almost nothing to do with VPNs (but more on that later).
PPTP is Pretty Poor Tunneling Protocol (oh, no, sorry, it's a Point to Point Tunneling Protocol...), and is the way Microsoft systems do VPN.
The "standard" way to do VPN (in other words, the method which is supported by most vendors, uses open standards, and also has the best security) is IPsec.
The usual way to do IPsec under Linux is to use FreeS/WAN under kernel 2.4, or the built-in IPsec under kernel 2.6.
I use FreeS/WAN, I like it, it works well with netfilter (once you've got used to the path the packets take at each end), and I'm happy with its 3DES/RSA security.
I said I'd mention more about SSH - that also uses good encryption and is therefore secure, and once you have an SSH connection between two machines, you can "tunnel" almost any network traffic you like between them, and it does work, although I wouldn't select this as a first choice for a VPN because there's a lot more manual setting up involved. IPsec is more like a network route - you just configure it, and let the two endpoint machines get on with negotiating the link, and then computers from whichever network ranges you've configured the VPN to support can connect to each other transparently through a nice secure tunnel across the Internet.
Hope this helps,
Regards,
Antony.
Quoted 9 lines · Gianni Pucciani
Quoted 5 lines · Antony Stone
PPP is Point-to-Point Protocol, and has almost nothing to do with VPNs :)
SSH is Secure Shell, and at least it contains some encryption, but again, is almost nothing to do with VPNs (but more on that later).
I thought that they could be used in conjuction to achieve vpn functionalities...
Er, well, actually, yes they can, however it is *really* ugly, it breaks some of the ways in which TCP works, and I wouldn't normally even let someone know it was possible until they'd exhausted all other sane ways to set up a VPN and failed for some reason.
The most common reason I know of for people wanting to create a VPN using SSH and PPP is when they're behind a firewall which doesn't allow them to create VPNs (using PPTP or IPsec) but does allow SSH - ie: as a way to bypass an organisation's security policy of not allowing personal VPN setups :)
As I said in my earlier reply, you can tunnel other protocols through an SSH link, and it turns out that this includes PPP.
Regards,
Antony.
Signature · 4 lines
Wanted: telepath. You know where to apply.
Please reply to the list;
please don't CC me.Quoted 19 lines · Antony Stone
PPP is Point-to-Point Protocol, and has almost nothing to do with VPNs :)
SSH is Secure Shell, and at least it contains some encryption, but again, is almost nothing to do with VPNs (but more on that later).
PPTP is Pretty Poor Tunneling Protocol (oh, no, sorry, it's a Point to Point Tunneling Protocol...), and is the way Microsoft systems do VPN.
The "standard" way to do VPN (in other words, the method which is supported by most vendors, uses open standards, and also has the best security) is IPsec.
The usual way to do IPsec under Linux is to use FreeS/WAN under kernel 2.4, or the built-in IPsec under kernel 2.6.
I use FreeS/WAN, I like it, it works well with netfilter (once you've got used to the path the packets take at each end), and I'm happy with its 3DES/RSA security.
Quoted 10 lines
I said I'd mention more about SSH - that also uses good encryption and is therefore secure, and once you have an SSH connection between two machines, you can "tunnel" almost any network traffic you like between them, and it does work, although I wouldn't select this as a first choice for a VPN
because there's a lot more manual setting up involved. IPsec is more like
a network route - you just configure it, and let the two endpoint machines get on with negotiating the link, and then computers from whichever network ranges you've configured the VPN to support can connect to each other transparently through a nice secure tunnel across the Internet.
You can also take a look at OpenVPN (http://openvpn.sourceforge.net). It's quite easy to set up, is crossplatform and can be made transparant. Also, it doesn't require kernel modification.
Regards,
Victor
Quoted 5 lines
Hope this helps,
Regards,
Antony.
Quoted 3 lines · Gianni Pucciani
Hi,
I forget one things, waht about the CIPE solution. I read that in the rh9 sec guide about VPN.
Yes, I should have mentioned that. It uses a different method for encrypting
the data than IPsec does (Blowfish instead of 3DES) and is therefore supposed
to be faster. However in my experience you need to have a *big* pipe to the
outside world in order to be encrypting so much data down your VPN that a basic CPU can't handle it.
I've never used CIPE so can't comment on it in practice.
I tend to use the standard which is supported by most other vendors for cross-compatibility, therefore I like IPsec.
Quoted 2 lines
And then, I see this news: the FreeS/WAN project is no longer in active development, it could be a problem?
I don't regard it as a problem - I think people will continue to use the latest version for setting up IPsec with Linux 2.4 kernels, and they'll migrate to using the built-in IPsec for 2.6 kernels.
The main reason that FreeS/WAN is no longer being developed is because although it works well as a VPN, the team don't think they can achieve one of their goals, which was Opportunistic Encryption (using DNS to hold public keys so that routers could create VPN tunnels on their own when they wanted to talk to each other, instead of being manually configured to set up specific tunnels).
In my opinion that doesn't stop it still being very useful as a way to configure standard IPsec links.
Regards,
Antony.
Signature · 5 lines
The difference between theory and practice is that in theory there is no
difference, whereas in practice there is.
Please reply to the list;
please don't CC me.Ok, I see.
Well, thank you very much for giving me such information and for being so exhaustive.
regards
Gianni
Quoted 35 lines · Antony Stone
Quoted 5 lines · Gianni Pucciani
Hi,
I forget one things, waht about the CIPE solution. I read that in the rh9 sec guide about VPN.Yes, I should have mentioned that. It uses a different method for encrypting the data than IPsec does (Blowfish instead of 3DES) and is therefore supposed to be faster. However in my experience you need to have a *big* pipe to the outside world in order to be encrypting so much data down your VPN that a basic CPU can't handle it.
I've never used CIPE so can't comment on it in practice.
I tend to use the standard which is supported by most other vendors for cross-compatibility, therefore I like IPsec.
Quoted 4 lines
And then, I see this news: the FreeS/WAN project is no longer in active development, it could be a problem?
I don't regard it as a problem - I think people will continue to use the latest version for setting up IPsec with Linux 2.4 kernels, and they'll migrate to using the built-in IPsec for 2.6 kernels.
The main reason that FreeS/WAN is no longer being developed is because although it works well as a VPN, the team don't think they can achieve one of their goals, which was Opportunistic Encryption (using DNS to hold public keys so that routers could create VPN tunnels on their own when they wanted to talk to each other, instead of being manually configured to set up specific tunnels).
In my opinion that doesn't stop it still being very useful as a way to configure standard IPsec links.
Regards,
Antony.
Quoted 8 lines · Gianni Pucciani
Hi all,
some of you can give me some input about the best way to set up a vpn under two Linux RH9 systems?
I heared there are different solution (PPP and SSH, PPTP...) and I'd like to know your opinion about that.
ThanksGianni
Like Antony, we prefer and utilize IPSec for network to network connections. In fact, our entire business model of global delivery of IT services from centralized GNOCs is built around it and have used it for very complex and very large site to site configurations (hundreds of gateways and thousands of users and planned for thousands of gateways and tens of thousands of users). We are in the process of transitioning from an extraordinarily powerful but obscure proprietary product to an open source solution.
The closest solution we could find to rival the commercial offerings on such a large scale is netfilter + freeS/WAN + iproute2 + ISC DHCP + StrongSec DHCP Relay + OpenCA. There are reasonable alternatives to OpenCA.
The FreeS/WAN code is alive and healthy. Two major cooperative forks are available. One is at www.openswan.org and the other is at www.strongswan.org. Both are well supported and helpful.
There a fairly complete although slightly dated slide shows on tying all these technologies together (other than OpenCA) in the training section of http://iscs.sourceforge.net.
The only major missing piece right now to make this combination a full-fledged competitor to the largest and most expensive commercial players is a sophisticated management front end such as those offered by Solsoft, SmartPipes, NetScreen, Checkpoint, etc. That is the hole I am trying to fill with the ISCS project. It is the last piece that we need before we can do with open source tools what we have previously only been able to do with commercial tools to achieve the scale and complexity we need. If anyone wants to help, it is a huge project and I can use all the help I can get!
Signature · 5 lines
John A. Sullivan III Chief Technology Officer Nexus Management +1 207-985-7880 [email protected]
lør, 10.04.2004 kl. 14.30 skrev John A. Sullivan III:
[...]
Quoted 13 lines
The closest solution we could find to rival the commercial offerings on such a large scale is netfilter + freeS/WAN + iproute2 + ISC DHCP + StrongSec DHCP Relay + OpenCA. There are reasonable alternatives to OpenCA.
The FreeS/WAN code is alive and healthy. Two major cooperative forks are available. One is at www.openswan.org and the other is at www.strongswan.org. Both are well supported and helpful.
There a fairly complete although slightly dated slide shows on tying all these technologies together (other than OpenCA) in the training section of http://iscs.sourceforge.net.
Quoted 9 lines
The only major missing piece right now to make this combination a full-fledged competitor to the largest and most expensive commercial players is a sophisticated management front end such as those offered by Solsoft, SmartPipes, NetScreen, Checkpoint, etc. That is the hole I am trying to fill with the ISCS project. It is the last piece that we need before we can do with open source tools what we have previously only been able to do with commercial tools to achieve the scale and complexity we need. If anyone wants to help, it is a huge project and I can use all the help I can get!
This was an enormously valuable precis and greatly appreciated. I wish I could help, but don't have access to a lab. If there's anything a single user set-up can do, let me know *at my sig below*.
--Tonni
Signature · 8 lines
Kattekots op de vloer na de moeë thuiskomst weinig walg getrouw als kind de kat heet welkom. mail: billy - at - billy.demon.nl http://www.billy.demon.nl
Quoted 31 lines · Antony Stone
Quoted 3 lines · Gianni Pucciani
Hi,
I forget one things, waht about the CIPE solution. I read that in the rh9 sec guide about VPN.Yes, I should have mentioned that. It uses a different method for encrypting
the data than IPsec does (Blowfish instead of 3DES) and is therefore supposed
to be faster. However in my experience you need to have a *big* pipe to the
outside world in order to be encrypting so much data down your VPN that a basic CPU can't handle it.I've never used CIPE so can't comment on it in practice.
I tend to use the standard which is supported by most other vendors for cross-compatibility, therefore I like IPsec.
Quoted 2 lines
And then, I see this news: the FreeS/WAN project is no longer in active development, it could be a problem?
I don't regard it as a problem - I think people will continue to use the latest version for setting up IPsec with Linux 2.4 kernels, and they'll migrate to using the built-in IPsec for 2.6 kernels.
The main reason that FreeS/WAN is no longer being developed is because although it works well as a VPN, the team don't think they can achieve one of their goals, which was Opportunistic Encryption (using DNS to hold public keys so that routers could create VPN tunnels on their own when they wanted to talk to each other, instead of being manually configured to set up specific tunnels).
Quoted 2 lines
In my opinion that doesn't stop it still being very useful as a way to configure standard IPsec links.
Development has moved to openswan
Quoted 14 lines
Regards,
Antony.
Signature · 5 lines
The difference between theory and practice is that in theory there is no difference, whereas in practice there is. Please reply to the list; please don't CC me.
---snip----
Quoted 2 lines
Development has moved to openswan
I believe openvpm is another good choice for ipsec vpn solution
Quoted 10 lines
Quoted 10 lines
Regards,
Antony.
Signature · 2 lines
The difference between theory and practice is that in theory there is no difference, whereas in practice there is.
Quoted 5 lines
Quoted 5 lines
Please reply to the list;
please don't CC me.
Aaron P. Martinez
I had a couple questions about the different methods talked about here, probably focusing on CIPE, FreeSWAN/OpenSWAN, and the OpenVPN (along with any others users may chime in with)
1. Where in the netfilter path do these solutions package up data? Important to know if we see tunnel/VPN packets or the contents which are going into them, both incoming and outgoing
2. Which of these guys support broadcast or multicast?
3. Do any of these support non-encrypted transmission? The reason for this would be if a higher level/later service provided the encryption over the risky sections of a transmission
4. What kind of overhead do these cost? I was curious from the perspective of initialization/updates and also any additional packet headers (rough guess).
Thanks ahead of time!!
-Scott
__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html
I'm afraid I don't have time to answer in depth today but here are a few quick answers regarding *swan:
Quoted 8 lines · Scott MacKay
I had a couple questions about the different methods talked about here, probably focusing on CIPE, FreeSWAN/OpenSWAN, and the OpenVPN (along with any others users may chime in with)
1. Where in the netfilter path do these solutions package up data? Important to know if we see tunnel/VPN packets or the contents which are going into them, both incoming and outgoing
*swan makes this convenient by passing the traffic from the physical interface to an ipsec interface, e.g., eth0 -> ipsec0. I believe there are extensive diagrams of how this works in the training section at
http://iscs.sourceforge.net
Quoted 9 lines
2. Which of these guys support broadcast or multicast?
3. Do any of these support non-encrypted transmission? The reason for this would be if a higher level/later service provided the encryption over the risky sections of a transmission
4. What kind of overhead do these cost? I was curious from the perspective of initialization/updates and also any additional packet headers (rough guess).
There are some performance benchmarks buries somewhere in the extensive *swan documentation.
Quoted 1 line
<snip>
Signature · 9 lines
John A. Sullivan III Chief Technology Officer Nexus Management +1 207-985-7880 [email protected] --- If you are interested in helping to develop a GPL enterprise class VPN/Firewall/Security device management console, please visit http://iscs.sourceforge.net
I can fill in some gaps ...
Quoted 12 lines · John A. Sullivan III
I'm afraid I don't have time to answer in depth today but here are a few quick answers regarding *swan:
Quoted 8 lines · Scott MacKay
I had a couple questions about the different methods talked about here, probably focusing on CIPE, FreeSWAN/OpenSWAN, and the OpenVPN (along with any others users may chime in with)
1. Where in the netfilter path do these solutions package up data? Important to know if we see tunnel/VPN packets or the contents which are going into them, both incoming and outgoing
Quoted 4 lines
*swan makes this convenient by passing the traffic from the physical interface to an ipsec interface, e.g., eth0 -> ipsec0. I believe there are extensive diagrams of how this works in the training section at
http://iscs.sourceforge.net
OpenVPN and CIPE also both use virtual devices, giving access to both the encrypted packets and the unencrypted contents.
Quoted 2 lines
Quoted 2 lines
2. Which of these guys support broadcast or multicast?
OpenVPN and CIPE both support bridging modes.
Quoted 4 lines
Quoted 4 lines
3. Do any of these support non-encrypted transmission? The reason for this would be if a higher level/later service provided the encryption over the risky sections of a transmission
OpenVPN supports unencrypted transmission. I don't think CIPE does, but I'm not 100% sure.
Quoted 5 lines
Quoted 3 lines
4. What kind of overhead do these cost? I was curious from the perspective of initialization/updates and also any additional packet headers (rough guess).
There are some performance benchmarks buries somewhere in the extensive *swan documentation.
The additional packet headers (of ANY tunnel protocol) can cause problems when accessing servers with broken path mtu discovery. This normally isn't a problem for internal VPN use, but you'll run into this when using a VPN to get internet access via a remote site's internet connection. (If you do this, Netfilter mss rewriting can be a big help.)
OpenVPN implements emulation of full-size mtu. However, turning this on can result in a significant (~30%) drop in speed, so I don't use it.
Otherwise, OpenVPN and CIPE (and probably *SWAN) run essentially at wirespeed - usually less than 1-2% speed cost. OpenVPN supports compression, and compressible transfers can run even faster than uncompressed wirespeed.
OpenVPN has become my personal VPN choice. I use it for a VPN linking my office and home and for a demonstration tunnel between upstate NY and New Zealand. (http://www.nz.netheaven.com) Previously I used mostly CIPE, and for Linux I still regard the choice a close call.
--
Dick St.Peters, [email protected]