Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question (and some more research) has revealed that OpenVPN isn't for me. So, what are my other options? In particular things I need/want (most important first) are:

  1. A server daemon that runs on Linux without kernel modules
  2. Clients work from behind NATs and Firewalls.
  3. Free/FOSS
  4. Support for PPTP, L2TP or L2TP/IPSec PSK/CRT
  5. A architecture that makes all accesses equal: if the server is to have access to the VPN, then it must be a client. Just like everyone else.
  6. Minimal configuration/state.

The first 3 are must haves and the last is a nice to have. The rest I could live without, but then again I could also live with nothing.

share|improve this question
Realize that the OP wants a VPN in which two clients communicate directly with each-other rather than passing traffic through the server, according to the other question linked from above. – Sean Reifschneider Feb 24 '11 at 1:41
@Sean: Note that I do want the VPN clients to talk to the server rather than directly to each other. What I don't want is for the server to simply forward all traffic from the tunnel to the host network stack for forwarding but rather implement the routing/switching in the daemon. – BCS Feb 24 '11 at 1:52
In particular, I want the choice of not having the VPN daemon create a network device. – BCS Feb 24 '11 at 2:01
Your 5th requirement rules out almost every single tool that exists. That requirement basically would mean that the VPN software on the server has to fully implement the networking stack within the VPN software. Almost every VPN server relies on the networking stack built into the host OS instead of trying to reinvent the wheel. – Zoredache Feb 24 '11 at 2:03
@Zoredache I'm kinda dubious that the delta between the packet handling they already need to do and what that would take is that large. Besides, it has a number of interesting advantages. Aside from what I'm looking for, it would avoid an extra pair of user-space/kernel-space transfers and who knows how many copies. – BCS Feb 24 '11 at 2:21

SSH might be your friend : it can port-forward and encrypts and is built-in to all good operating systems :-)

share|improve this answer
Sadly, ssh port forwarding doesn't provide proper network support: for one thing, I can't offer to forward to any port on more than a single end point because that would require the ssh client to listen to every port and then it would have no way to tell which endpoint to forward to. – BCS Feb 24 '11 at 1:42
@BCS, with the correct support on the SSH client you can achieve a full layer 2 tunnel between the SSH client an the server without doing forwards. But the steps you would need to follow would break your 5th requirement, just like OpenVPN. – Zoredache Feb 24 '11 at 2:00
I think the OP has conflicting set of ideas/requirements and needs to break up his set of requirements and accept some form of VPN subnet or bridging interfaces. I.e. his set of requirements can not be met with finding/making a single application, even it was programmed from scratch. I would say to him: get used to the idea of VPN end-points, trust certificates and firewalling. – DutchUncle Feb 24 '11 at 11:15
And then there's the first requirement: as I understand it, the Linux way is to integrate stuff into the kernel to increase performance: so is the OP trying to reduce performance, or would he be happier with a BSD style operating system? – DutchUncle Feb 24 '11 at 11:20
#1 is a result of not having the access needed to use anything else. – BCS Feb 24 '11 at 17:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.