Freelan - an open-source, multi-platform, peer-to-peer VPN software(freelan.org)
freelan.org
Freelan - an open-source, multi-platform, peer-to-peer VPN software
http://www.freelan.org/
9 comments
Hey, the shameless plug would have been a lot better with a link to a Github repo. I'd advise you to put it up on Github and keep advertising it, good NAT traversal algorithms are probably worth something for open source projects.
Not an expert, but TeleHash [1] might be a more lightweight alternative than freelan for a lot of applications.
[1] https://github.com/quartzjer/TeleHash/blob/master/org/v2.md
[1] https://github.com/quartzjer/TeleHash/blob/master/org/v2.md
wow, I didn't follow this field for a while. Seems to be a great thing, but it's not an alternative, it's a higher layer. Telehash may provide naming, addressing, etc, while the stack I'm talking about basically provides UDP connectivity between parties.
For a otherwise very interesting and up-vote worthy comment, I really don't know what to do with comments that also include derogatory terms.
The project sound interesting, the comment is very much relevant in today's post-NSA world. So should I downvote, upvote, or not vote at all? If the comment had used a neutral word, rather than a derogatory term, it would not be a question about it.
The project sound interesting, the comment is very much relevant in today's post-NSA world. So should I downvote, upvote, or not vote at all? If the comment had used a neutral word, rather than a derogatory term, it would not be a question about it.
I'd admit a wrongdoing if you can explain how to poison a project with BSD. For me (not an expert in OSS licenses in any way) it sounds like "the victim was poisoned with glass of pure water".
You can vote whatever you feel like, but I'm not selling my opinion for a vote on HN. My opinion is what it is and I can change it if you either provide sufficient argument or threaten my life, health, family or some other factor of my life, more important than my opinion on OSS licensing :-)
I can provide argument why I think GPL is what I think it is, but I seriously doubt this thread is the right place for it.
You can vote whatever you feel like, but I'm not selling my opinion for a vote on HN. My opinion is what it is and I can change it if you either provide sufficient argument or threaten my life, health, family or some other factor of my life, more important than my opinion on OSS licensing :-)
I can provide argument why I think GPL is what I think it is, but I seriously doubt this thread is the right place for it.
>I'd admit a wrongdoing if you can explain how to poison a project with BSD.
You could always include the advertising clause.
You could always include the advertising clause.
I don't feel this as "poison" but point taken, thanks.
We didn't use the clause though and didn't use (as far as I remember) any code which did.
We didn't use the clause though and didn't use (as far as I remember) any code which did.
Users of BSD software still need to follow the BSD license. This mean for 4 clause BSD that you must including the line "This product includes software developed by the <organization>." in All advertising materials. If you are using the Revised BSD License, you still need to include the BSD license in any documentation or "other materials" that is shipped.
So if you like to be in full control over your advertisement, and your documentation, bsd do indeed "poison" the project. It clearly adds restrictions. I would however not use such derogatory term when describing the BSD. Is it really that hard to avoid using derogatory terms and simply use language without it?
So if you like to be in full control over your advertisement, and your documentation, bsd do indeed "poison" the project. It clearly adds restrictions. I would however not use such derogatory term when describing the BSD. Is it really that hard to avoid using derogatory terms and simply use language without it?
I wrote specifically "BSD-type" not BSD. We didn't use BSD license itself, as far as I can tell and the project contains surprisingly small amount of _any_ third party code.
I do not consider "poisonous license" a derogatory term. English is not my native language, may be this is why.
I do not consider "poisonous license" a derogatory term. English is not my native language, may be this is why.
That's fair. I consider calling anything, be that GPL, BSD, or open source as poisonous as to be on the side of derogatory term, similar to the cancer comparison made by Steve Ballmer. I can see however if that’s not always the case for others.
Just as a side note, I found an half year old HN article which talked about the BSD requirements, with suggest that one might want to use ISC license in some cases: https://news.ycombinator.com/item?id=5798431
Not that your project is code for embedded software (or is it? C code tend to be quite fast and have small memory footprint), but it might be an interesting read.
Just as a side note, I found an half year old HN article which talked about the BSD requirements, with suggest that one might want to use ISC license in some cases: https://news.ycombinator.com/item?id=5798431
Not that your project is code for embedded software (or is it? C code tend to be quite fast and have small memory footprint), but it might be an interesting read.
We designed and coded it with embedded in mind. We both have extensive embedded experience and it was a no brainer with all that hype about "internet of things". Our stack is naturally born IPv6 and as such is a natural match for "things", so not thinking about embedding would have been clearly a mistake.
>So if you like to be in full control over your advertisement, and your documentation, bsd do indeed "poison" the project.
The real trouble with the advertising clause is that it breaks compatibility with several other common licenses. Some of the BSD advocates actually like this because it causes trouble for people who use GPL code (the usual holy war justifications), but the net result is still that you have two otherwise-useful pieces of code that become mutually incompatible for political reasons.
The real trouble with the advertising clause is that it breaks compatibility with several other common licenses. Some of the BSD advocates actually like this because it causes trouble for people who use GPL code (the usual holy war justifications), but the net result is still that you have two otherwise-useful pieces of code that become mutually incompatible for political reasons.
Specifically what NAT traversal methods did you use? I'm always interested to hear about new ones I may not know about.
I'd be very interested to check it out if it lands on GitHub. I don't think I'd be much of a contributor up front, I'm still getting my head around all the acronyms tossed around VPN networking, but I have a hobby project for which I've been researching how to build something like this.
+1 for Github, I could think of some uses for this.
[deleted]
I would like to see your project take off - but I would prefer to see such projects as AGPL3.
why (AGPL3) ?
Requiring the source code to be generally available and shared is, I think, a pre-requisite for a trustworthy computing environment.
Look, I was born, raised and spent most of my life in the country government of which considered themselves the one and only source of what is good and what is bad for 70 years. Actively punishing people for disobedience for "greater good". This great experiment came at the price of just a few tens of millions dead people, besides other things. And it didn't end well - country, being one of the superpowers of the world, basically disappeared overnight.
Since then, when I hear "greater good" I feel an urge to kill (only half joking here). And "requiring the source code" sounds pretty much like "greater good" for me. If I'm releasing the code, then I'm releasing it. If I think that some asshole, who invented the best smartphone on the planet, will use it for his own profit and if I feel pain thinking so, I'm not going to release it. Releasing source code and attaching a piece of political agenda to is is not a coding activity, it's a specific kind of political activity - a political propaganda. "When I hear the word propaganda I'm reaching for the gun".
Since then, when I hear "greater good" I feel an urge to kill (only half joking here). And "requiring the source code" sounds pretty much like "greater good" for me. If I'm releasing the code, then I'm releasing it. If I think that some asshole, who invented the best smartphone on the planet, will use it for his own profit and if I feel pain thinking so, I'm not going to release it. Releasing source code and attaching a piece of political agenda to is is not a coding activity, it's a specific kind of political activity - a political propaganda. "When I hear the word propaganda I'm reaching for the gun".
hehe, well, if you make it available with bsd3/mit, if someone really wants they can gpl it, so anyone arguing that it must be gpl from the get go should just commit to forking it :)
(you know you're doing well when folks want to fork you!)
I'm not going to point a gun at your head and make you do it. Sorry for irritating you. Peace.
throw it on bitbucket with some sort of bsd/mit style license and share it with the world.
or at least do it and get enough folks excited that some volunteers help add docs :)
do it!
or at least do it and get enough folks excited that some volunteers help add docs :)
do it!
Very interested to see something like this.
After skimming the website and the FAQ[1] it seems to be a safer tinc[2]. It's a very cool piece of software and I always wanted to set something like that up between my servers and routers but never found a need convincing enough to go through the trouble.
[1] http://www.freelan.org/page/faq
[2] http://www.tinc-vpn.org/
[1] http://www.freelan.org/page/faq
[2] http://www.tinc-vpn.org/
The points why freelan is better regarding security are no real issues, but tradeoffs in terms of performance which just copy-pasted from the tinc-vpn security faq[1].
I have been using tinc for quite a long time and it feels pretty stable, but the configuration of new nodes is quite a PITA. For that reason a lot of bootstrapping scripts have been built around this [2]. Also, i love the possibility to easily dump the whole (known) network graph and create great graphs from this info [3].
I am using it mostly for reaching hosts behind NAT and creating a secure environment for these hosts.I never have tried the 'connect whole network' feature.
[1] http://www.tinc-vpn.org/security/
[2] https://github.com/krebscode/painload/blob/master/retiolum/s...
[3] http://euer.krebsco.de/graphs/retiolum/retiolum_1.svg
I have been using tinc for quite a long time and it feels pretty stable, but the configuration of new nodes is quite a PITA. For that reason a lot of bootstrapping scripts have been built around this [2]. Also, i love the possibility to easily dump the whole (known) network graph and create great graphs from this info [3].
I am using it mostly for reaching hosts behind NAT and creating a secure environment for these hosts.I never have tried the 'connect whole network' feature.
[1] http://www.tinc-vpn.org/security/
[2] https://github.com/krebscode/painload/blob/master/retiolum/s...
[3] http://euer.krebsco.de/graphs/retiolum/retiolum_1.svg
Tinc's problematic protocol (security wise) killed it for me before. For example, it didn't have pfs.
It seems that with 1.1pre3 or 4 they have gotten a new, experimental protocol. Hopefully it is an improvement.
It seems that with 1.1pre3 or 4 they have gotten a new, experimental protocol. Hopefully it is an improvement.
A little pet peeve, why do people always overlook the most ubiquitous VPN solution of them all?
OpenSSH
Can create a full spectrum VPN & supports a stronger and a broader range of ciphers than virtually all competing software, is entirely open source, runs on every platform I can think of, the list goes on. Heck via pointopoint it can even mimic freelan and be peer to peer :)
OpenSSH
Can create a full spectrum VPN & supports a stronger and a broader range of ciphers than virtually all competing software, is entirely open source, runs on every platform I can think of, the list goes on. Heck via pointopoint it can even mimic freelan and be peer to peer :)
Because...
• TCP-in-TCP (or ${ANY_RELIABLE_STREAM}-in-${ANY_RELIABLE_STREAM}) performs very poorly in the face of packet loss.
• SSH itself becomes a bottleneck on networks with a large bandwidth-delay product because of statically sized buffers in the client and server. (Though there's been some work done in OpenSSH to mitigate that.)
• "Real" VPN software generally has niceties like MSS mangling TCP connections inside the tunnel to help prevent fragmentation of the encapsulated packets due to VPN overhead.
SSH is great when you need a quick and dirty tunnel (I use it in SOCKS mode a fair bit), but it's not something I'd want to use for long-lived tunnels that will see a lot of data.
• TCP-in-TCP (or ${ANY_RELIABLE_STREAM}-in-${ANY_RELIABLE_STREAM}) performs very poorly in the face of packet loss.
• SSH itself becomes a bottleneck on networks with a large bandwidth-delay product because of statically sized buffers in the client and server. (Though there's been some work done in OpenSSH to mitigate that.)
• "Real" VPN software generally has niceties like MSS mangling TCP connections inside the tunnel to help prevent fragmentation of the encapsulated packets due to VPN overhead.
SSH is great when you need a quick and dirty tunnel (I use it in SOCKS mode a fair bit), but it's not something I'd want to use for long-lived tunnels that will see a lot of data.
SSH is quenched by many firewalls in corporate and hotel networks. Not just blocking port 22 but also dropping the packets based on protocol inspection.
There are hacks to tunnel SSH over HTTPS ( really ) but at that point you've abandoned the simplicity of SSH and might as well go with OpenVPN.
There are hacks to tunnel SSH over HTTPS ( really ) but at that point you've abandoned the simplicity of SSH and might as well go with OpenVPN.
Oh yeah, Corkscrew! I used that many times! :)
It's not P2P unless at least one of the P's is directly accessible.
It takes longer to read the man page than to spin up an AMI with openVPN. That's my only excuse. :)
Its not trivial (afaik) to route all traffic over an OpenSSH connection on most platforms is it? I mean you can have it act as a SOCKS proxy without much trouble but there's no easy way to route DNS lookups over it is there?
It is trivial, I use this simple script to open an SSH tunnel to a remote host, assign me and the remote host private IP on tunnel interfaces (/dev/tun0), setup a pointopoint route between them, nuke my regular routing table & and fix it so my default route points down the newly created tunnel.
http://pastebin.com/CxaH6z49
http://pastebin.com/CxaH6z49
I wouldn't really call that trivial compared to enabling a VPN connection in most operating systems (i.e. clicking on the vpn icon and saying enable).
Also it appears to require root access on the remote machine which would make it difficult to securely let a few people use it. Definitely a useful script for a quick linux to linux tunnel.
Also it appears to require root access on the remote machine which would make it difficult to securely let a few people use it. Definitely a useful script for a quick linux to linux tunnel.
There's sshuttle: https://github.com/apenwarr/sshuttle
Firefox can be made set to do its DNS lookups over SOCKS:
http://support.vpnsecure.me/articles/ssh-tunnelling-proxy-tr...
http://support.vpnsecure.me/articles/ssh-tunnelling-proxy-tr...
When comparing with OpenVPN, they say the latter "does not allow direct client-to-client communication." Can anyone explain it? I thought point-to-point mode was not only supported, but the default.
I think the key word there is "direct" -- AFAIK FreeLAN is P2P, where OpenVPN is "client -> server -> other client"
OpenVPN is client/server in cert authenticated mode and P2P in symmetric mode. What it doesn't do is routing, so for creation of darknets you need a proper routing daemon, and non colliding IPs. Nor does it tunnel NAT (but it can connect from in NAT to outside, so a group in NAT can be bridged by a hub node on the internet).
But the semantics are silly if you can just host your own server.
[deleted]
With freelan, once the client has established a connection with any other known and accessible freelan client, a direct client-client connection can be made to anyone on the network, even if they are behind a NAT/firewall. I believe it's through a combination of tun/tap, UDP-punching, and proxying, but don't know for certain.
OpenVPN establishes a site-to-site or point-to-site VPN, but routing to the client still goes through the gateway server.
Freelan still requires a known "supernode" to broker the initial connection, but after that, they can either communicate directly or through peers.
OpenVPN establishes a site-to-site or point-to-site VPN, but routing to the client still goes through the gateway server.
Freelan still requires a known "supernode" to broker the initial connection, but after that, they can either communicate directly or through peers.
I can't figure out what they are talking about, and documentation on the main site is little to none. There are a few examples, but the actual binaries and config file locations are not documented on the website. I would have to download and install to read more. I suspect english may not be a first language here. I am also very suspect of anyone who uses real-word valid IP addresses in examples, rather than RFC1918 addresses.
My reading of it is that they appear to be saying that freelan does transparent NAT traversal, whereas OpenVPN would require explicit port-forwarding.
Scratch everything I said below. After reading what little documentation there is on FreeLAN, which isn't much, it looks like just another VPN solution like all the rest with nothing really special about it. The configuration looks different and it is interesting, but I don't see anything that makes it special, and the products claims of superiority over others seem unfounded.
--
I just happen to be here doing my first OpenVPN implementation this last few days.
It appears that FreeLAN is all about transparent bridging VPN, rather than routing VPN. Thus, the "LAN" part of the FreeLAN product name is particular apt.
It is noteworthy that the words "Ethernet" and "bridging" are absent from the product FAQ. This is most unfortunate.
--
I just happen to be here doing my first OpenVPN implementation this last few days.
It appears that FreeLAN is all about transparent bridging VPN, rather than routing VPN. Thus, the "LAN" part of the FreeLAN product name is particular apt.
It is noteworthy that the words "Ethernet" and "bridging" are absent from the product FAQ. This is most unfortunate.
[deleted]
it is the default... (for most practical definitions).
Could this take advantage of Google's new QUIC protocol, or get any benefits from it?
http://en.wikipedia.org/wiki/QUIC
http://en.wikipedia.org/wiki/QUIC
Pretty good idea, indeed!
I'm sure there are major typos in the configuration wiki( https://github.com/freelan-developers/freelan-all/wiki/Two-h... ), which prevent me setup two nodes within the same LAN.
So this can be an open-source replacement for Himachi/Log-me-in?
It's similar in that it's peer-to-peer, but doesn't require an auth/directory server to establish connections. If any known peer is accessible, the two can authenticate directly.
To successfully traverse many NATs you need a third party, which is already accessible from two parties trying to handshake.
Yep, that's what I meant by "accessible" too. But with Hamachi, there's a central service for client authentication. With freelan, peers authenticate directly via signed crts.
I looked into this heavily over the past few days. The punchline is this needs support for NAT traversal and some type of out-of-band way for clients to find each other.
NAT traversal is an implementation thing, and I favor Jabber as the out-of-band these days since everyone can get at least a GTalk account.
Though we now have libjingle, which basically merges both of these things and would probably elegantly solve the problem. But p2p vpn's aren't much use if you have to control the NAT router you're attached to.
NAT traversal is an implementation thing, and I favor Jabber as the out-of-band these days since everyone can get at least a GTalk account.
Though we now have libjingle, which basically merges both of these things and would probably elegantly solve the problem. But p2p vpn's aren't much use if you have to control the NAT router you're attached to.
> I favor Jabber as the out-of-band these days since everyone can get at least a GTalk account.
Isn't that deprecated in favour of Google Hangouts?
Isn't that deprecated in favour of Google Hangouts?
Whatever they're calling it, you can still get free XMPP accounts easily.
If it has been tied to hangouts then it has been tied to g+ and their ridiculous policies, I hardly class it as a good alternative.
Doesn't seem to be a problem with connecting with Pidgin, and I had it working with Wippien (sadly Wippien doesn't really work great with Win 7 or Linux).
Google has stopped federating with other Jabber services. They have replaced the GTalk Android app with the Google Hangouts app. They have started pushing people (forcibly) towards Google Hangouts instead of Google Talk. How long before XMPP support is dropped? I don't think we can claim that Google will keep it around for certain.
There are many other options, though: http://xmpp.net/
Not if one user is on Google Hangouts, and the other user isn't. Google dropped federation a while ago.
For VPN purposes, a throwaway Jabber account you use solely for that is perfectly acceptable though. The thing needed here is mostly a channel for two hosts to find their public IP addresses and communicate that information.
p2pvpn <http://www.p2pvpn.org/> uses BitTorrent trackers for it - which is actually a pretty good solution, but sadly also - no NAT holepunching or even UPnP yet.
Though I have been trying to find a VPN which uses a Tor hidden service to define network rendeavous point - since Tor is distributed and available, you could issue invites with the hidden service ID, and then send real IPs to members to establish P2P (so, not using the anonymity, just using it to bootstrap the network). SocialVPN does something similar, but I couldn't get it work reliably in tests (it would go up...then my hosts went down and I couldn't get them to appear to each other again).
p2pvpn <http://www.p2pvpn.org/> uses BitTorrent trackers for it - which is actually a pretty good solution, but sadly also - no NAT holepunching or even UPnP yet.
Though I have been trying to find a VPN which uses a Tor hidden service to define network rendeavous point - since Tor is distributed and available, you could issue invites with the hidden service ID, and then send real IPs to members to establish P2P (so, not using the anonymity, just using it to bootstrap the network). SocialVPN does something similar, but I couldn't get it work reliably in tests (it would go up...then my hosts went down and I couldn't get them to appear to each other again).
Isn't the upnp feature of most home routers enough?
For that I'd recommend tinc [1].
1: http://www.tinc-vpn.org
1: http://www.tinc-vpn.org
anyone tried to install on windows 2003 server? no service creates on installation. Also I tried to install service manually "freelan --install" but getting an error.
Error: An invalid argument was supplied.
Any idea how to run on Windows 2003 32bit server.
Any idea how to run on Windows 2003 32bit server.
I'm not sure you'll get an answer here. :-)
These are a better bet:
http://www.freelan.org/page/contact
How does this compare to Openswan for building multi lan tunnels?
In the wake of the recent NSA-related news I thought that this stuff may find a new use. If you have an idea and would like to devote some time and effort - you're welcome (I guess my contact info is visible in the profile).
I have no issues opensourcing it, it contains no close licensed and/or GPL-poisoned code. Everything we borrowed was BSD-type licensed. I just want to have some product to opensource instead of just dumping it on the Github and then waiting 4 billion years for life to conceive itself there :-)
Sorry for shameless plug.
Update for "Github ++" commenters: I'm all in to put it on Github (BitBucket is more natural in my case, because it's a Hg repo). But: the architecture was quite well thought out and internal APIs are quite clear, but they're not documented. We didn't have immediate open source plans. You wont be able to figure out how to use it, especially if you're going to use our "lower" layer - NAT traversal and friends. You need to know how it works to build a more universal API on top of it. Trust me, I know what I'm talking about - I did a few experiments with this code about a year ago and I spent a _lot_ of time figuring out how we did this and that. And it was _our_ code, we wrote it and discussed it daily for two years.