Slashdot Mirror

I have set up and supported remote sites and home based telecommuting. Listen to my advice, listen very carefully and save your sanity.

If your organization is large enough then it is likely that you will have a few older desktop PCs that have been or are due for replacement during an upgrade cycle. PCs that are inadequate for Microsoft XP and Office2003 are more than powerful enough for many current versions of Linux, especially for the role of server. Also second hand PCs with the required specifications are very cheaply acquired.

1) Find an older PC, at least a PII 300 with 256 MB memory, to set up as a headless ( no display or keyboard ) server and firewall. A simple web based interface ( or even an external hardware push button ) can be used by the local users to start/stop the server and internet connection. All other maintenance should be handled remotely via ssh, webmin and VNC.
2) Install a second NIC or connect the modem directly to the server. Connection to the Internet should be through the server and connection to the Office should be through a VPN on the server. Use a dynamic IP service for each site so you can remotely log on to the local server via ssh.
3) Install a new IDE hard drive in a 3.5" removable rack and tray. The drive should be than big enough for the operating system (Linux of course) and copies of some of the local desktop partitions. A telecommuter can shut down the server and bring in the drive during the day to resync and repair.
4) Install a DHCP demon on the local server to allocate local IP addresses, DNS and gateway settings. If the desktops are network boot capable then install TFTP to remotely boot and use Knoppix via PXE and the network. If the desktop OS is constantly crashing, or is infected by malware, the user can select PXE/network boot via the BIOS, and boot into Knoppix. The user can then be instructed over the phone to enable the ssh server to allow remote scan,repair and reimaging of the desktop partitions. The user can use the Knoppix desktop to continue working with full access to files while the the remote administrator fixes/reimages the drive in the background.( Consider hiring someone who knows how to customise Knoppix or another live Linux system for your setup )
5) Partition the desktops with as small as required C: partition ( or in the case of Linux the root partition ) for software. When software is install, use dd and netcat via live Knoppix to copy/clone a snapshot of the partition to the server. You can allocate the remaining free space as a persistent partition where documents are stored.
6) Install and enable remote VNC service on all the platforms, but only allow incoming connections from the local server ( which is redirected over a SSH tunnel ).
7) For local backup, create share directories on the desktop accessible by the server. On the local server create loopback encrypted file systems, unmount and copy the images to the desktops shares in chunks, using redundancy if enough space is available on the desktops. Checksum ( MD5 is enough ) each piece.
8) If the network load to the Office is taking up all the available internet bandwidth or the connection is just too slow then install proxy servers on the local server. You can also consider using a distributed filesystem ( OpenAFS is still the best ) wi

... the Chinese, Russians, Americans, etc come looking for me because I use http://www.openpgp.org/, http://www.truecrypt.org/, and http://www.openvpn.net/.

-terrified Canadian

Hmm, i didn't have much problems doing this. For earlier versions of Linux, a kernel patch for MPPE was required, but since then this has been integrated into the Linux kernel. For some time, there was a rather nasty bug in the Linux kernel, preventing MTU detection from working PPTP MTU Problems - but this has been resolved since then.

I've looked at these solutions again about half a year ago. At that time, i didn't feel comfortable guiding a sales rep or a person with similar IT know how through the procedure through the phone - this is different with Windows's and OS X's PPTP client - they're idiot proof. And that's my main reason for using it.

And more problems; OpenVPN and u:pw authentication against Active Directory doesn't seem to be easily possible.

I use OpenVPN a lot, but only for site-to-site configurations. For roadwarriors, i recommend PPTP.

Why?

Both OS X and Windows (from 2000) have a native PPTP client. PPTP uses GRE, so it doesn't work with routers that don't support VPN Passthrough, but nearly 99% do. The ease of deployment of PPTP is massive - OpenVPN requires a lot more work, and isn't as nicely integrated into the OS as PPTP on both OS X and Windows.

Just to add to your list: anoNet

Unlike the others you listed, anoNet is a full IP network built using standard OSS tools (OpenVPN and Quagga being the heart of the network).

It is far from a perfect at giving absolute anonymity at the software level, it requires you to use some common sense. On the plus side, *you* get to decide who you trust and how much you trust them. Like TOR, the more people that are a part of anoNet, the more anonymous the network becomes. Think of the network in terms of old school BBSs.

If you are looking to join a network and just find loads of warez/porn/etc. anoNet is probably not for you. There is nothing to stop someone from hosting a warez site, and inside the network you are pretty darn safe. The reason you won't just find a huge stash is the fact that the network was built by people that believe in their privacy / right to free speech above all else. We are a bunch of network admins / Unix admins / programmers. Obviously we have no reason to pirate software since *nix is our OS of choice.

anoNet is what we call a Democratic Anarchy. There is a nice page on our wiki (inside the network) on what that means, but it is way too much to define here. Bottom line there is no kiddie porn, there will be no kiddie porn and don't bother connecting if you want to debate how not allowing kiddie porn is censorship. We picked a line, that line was kiddie porn and we stick to it.

Windows users are more than welcome. Because there is no BGP implementation for Windows, Windows users can't "natively" be routers, they can get a static IP (or a whole subnet) however. We have a coLinux image that can get you up and running if you really wanted to be a router.

Lastly, we are willing to help you learn. I can't express that enough. If you want to learn about networking or any other aspect of the network, we are all willing to help if you are genuinely interested. If you just want to setup a node and be a part of the network, that is fine also.

Anyway, hope this post tickled the imaginations of at least a few people. If you decide to connect, use a pseudonym that you have never used anywhere else.

so how would the router would know the difference between https traffic and a vpn running over port 443? http://openvpn.net/ for instance...

It seems like when you say SSL, you mean web based. And when you say IPSec, you mean Full IP Access.

http://openvpn.net/
http://sourceforge.net/projects/sslexplorer

*sigh*

http://openvpn.net/

..BUT! I don't rely on separate ip ranges as security. This aproach is in my view pretty risky - If someone in the know would stumble upon this WLAN, they would certainly be intrigued. Then the ip range thingy would pretty soon be spoofed as soon as someone sniffs a couple of his packets. On my network I have a firewalled interface to the wlan, presenting DHCP, OpenVPN and a thttp server running a blinkenlights MOTD (all traffic redirected to this) :) Offcource the thttpd is an added security risk, but I like to have some sort of feedback on this not being OK with me :)

i agree with parent on the fact that programs like this have a different aggenda, not everyone wants the `powers that be` to have somthing on them, look at the people working on anonet, they have got so fed up of the current internet and started to form their own over the top using VPN's. not only that, they also offer a somthing that projects like tor cant do, true ip access! you no longer need to find a way to proxy applications, just download a vpn client like OpenVPN and play.

i am so stoked that there are people out there that still care about their anonymity like me, even if i have nothing to hide, i dont want to be tracked and profiled by the type of browsing i do, and not have everything coming back to huant me. if you are a real geek theres plenty of space for you on anonet, plenty of networking stuff going on.

i hate to say it now but there is a thin line between repressed countrys such as china and iran compared to 'land of the free' america and now canada, england, france, germany and probably more, take back what belongs to you, have the choice to view what you want at your discresction without being profiled.

That should be http://www.openvpn.net/.net, not .org....

oh crap!
apologies, and thanks for the correction!
dont know what the heck I was drinking...

That should be http://www.openvpn.net/.net, not .org....

We have all the tools we need. Check out OpenVPN http://openvpn.net/ Plus, a VPN network _does_ infact exist. It's called anoNet (which I have posted about before on this article, but is more appropriate in this thread). You can find all the details at http://anonet.org/ Plus, Freenet tends to be laggy from my experience. :(

OpenVPN runs on: Linux, Windows 2000/XP and higher, OpenBSD, FreeBSD, NetBSD, Mac OS X, and Solaris. An OpenVPN PocketPC port is under development.

Do think of all your options. Since I don't know of any thumb drives that'd be useful, here's what I'd recommend:

I suggest you set up a dedicated backup server at each site. It doesn't have to be much of a box -- it may even cost less than the thumbdrive. We used BackupPC to manage the backups -- it's entirely automated, and it can be configured to send out an email if a backup didn't complete successfully. It'll be doing mostly incremental backups. Keep the backups on a separate partition, so you can use something like DRBD over OpenVPN to backup a more central location, which has some sort of IT staff and can handle things like putting the whole thing on a RAID, maybe even swapping out removable hard disks to take home, and of course taking snapshots just in case the filesystem itself decides to die.

Others have talked about keeping everything at multiple datacenters, so that your backup is simply that any one can be hit by a tornado and none of your branch offices even notices. That's a lot more complex than what I've described, and if your DRBD/OpenVPN should lose its connection, local operation will likely still happen -- thus backups will still happen, if only to another local hard drive.

As far as "easy to use", that's not good enough. You want "Automatic". The datacenter is really your best option, with some sort of custom software or a web-based interface. Short of that, the packages I've described will hopefully be reasonably easy to implement, and the restores can happen from a web interface. It's a bit "do-it-yourself", but in a sysad way, not a full-time-programmer way.

Physical security, I leave to you. But if you must, it's certainly easy enough to encrypt the entire hard disk. However, if someone's able to carry off your backup computer, you're probably already hosed, and in any case, they only get information related to the local branch, I hope. Your datacenter/backupcenter would obviously be much more secure, but if the whole thing goes boom, your branch offices still work, and when you bring up a new datacenter, at worst, the branch offices have to reboot the backup server. And even that can be avoided with a few cron jobs.

The thumb drives are doubtless easier to implement -- buy one, plug it in, it works -- but if you get a knowledgeable IT staff to put together a system like the one I've described, it will pretty much run itself, and be mostly free of the whole "human error" problem -- the problem of, say, the guy who forgot to backup the data that day, or the idiotic tech who, rather than backing up, decided to use the thumb drive as primary storage, or the thumb drive that went through the wash, or the building that burnt down with the thumb drive and what it was backing up inside, or that one virus that manages to get into your data, hiding for awhile before it starts destroying things, so you restore from backup, only to find the same virus in every backup.

Oh, and one more thing -- whatever you choose, test it. And by "test it", I mean take all the hardware out of the branch office, bring in brand new hardware, and try to restore from your backup. There's no meaningful test of a backup other than actually attempting to restore it, if for no reason other than to prove to your superiors, customers, and the world in general that your backup is absolutely bulletproof.

Windows remote desktop suffers from very weak authentication. The best solution to this VNC flaw and using remote machines in general is to use a VPN to ensure that authentication is managed with public key cryptography, with all data thereafter being encrypted with symmetric keys. It also means it's so much simpler to run different services without having to create separate SSH tunnels. http://openvpn.net/ has a great solution working on all platforms.

I've been using OpenVPN to connect to my server and nat thru it to a client's network :

[home] -(openvpn1)-> [my company network server] -(NAT on openvpn2)-> [client's network].

works perfect, and setup was extra easy on a gentoo server.

check out the howto, especially the quickstart guide to get an idea of how it works.
I'm using it alongside Shorewall (in each vpn conf I assign a particular tun device, which I can refer to in the shorewall conf.. this makes traffic rules configuration as trivial as something like "Web/ACCEPT local_net vpn1".

We looked at OpenVPN. It looked like a lot of work to get it to function behind a NAT firewall. A google search restricted to the OpenVPN web site brings up many, many questions, and not many answers.

Anyone have experience?

You could look at OpenVPN

I really like OpenVPN. It works as a client or a server on Windows, Linux, FreeBSD, Mac OS X, and other operating systems, and it is pretty easy to install, configure, and run. I just followed the how-to. It operates over UDP or TCP, you can tunnel it through HTTP or SOCKS proxies, and the server can use any cipher or hash available in the OpenSSL library. PPTP is ubiquitous, but it has serious flaws. IPSEC is supposed to be standard, but interoperability is a configuration nightmare (especially if you try to do something complex, like use X.509 certificates, or something non-standard, like authenticate users against RADIUS). Firewall/NAT traversal can present serious challenges in some cases as well, as some firewalls can't handle non-TCP/UDP protocols. CIPE requires special support in the operating system kernel and only works on Linux and Windows, and tunneling TCP over TCP (when running PPP over SSH) is a really bad idea.

I'm using OpenVPN to tie routers running OpenWRT (Linux), routers running FreeBSD, and workstations/laptops running Windows, FreeBSD, and Mac OS X together. It works flawlessly.

I really like OpenVPN. It works as a client or a server on Windows, Linux, FreeBSD, Mac OS X, and other operating systems, and it is pretty easy to install, configure, and run. I just followed the how-to. It operates over UDP or TCP, you can tunnel it through HTTP or SOCKS proxies, and the server can use any cipher or hash available in the OpenSSL library. PPTP is ubiquitous, but it has serious flaws. IPSEC is supposed to be standard, but interoperability is a configuration nightmare (especially if you try to do something complex, like use X.509 certificates, or something non-standard, like authenticate users against RADIUS). Firewall/NAT traversal can present serious challenges in some cases as well, as some firewalls can't handle non-TCP/UDP protocols. CIPE requires special support in the operating system kernel and only works on Linux and Windows, and tunneling TCP over TCP (when running PPP over SSH) is a really bad idea.

I'm using OpenVPN to tie routers running OpenWRT (Linux), routers running FreeBSD, and workstations/laptops running Windows, FreeBSD, and Mac OS X together. It works flawlessly.

As far as OpenVPN you are deeply mistaken. It has nothing to do with IPSEC. It uses TLS over TCP or TLS over UDP. The second case requires some sequencing. None of the packet formats has anything to do with the IPSEC RFCs, the OS level abstractions have nothing to do with the RFCs and the keying is not anywhere near the madness specified in the IKE RFC.

"OpenVPN uses an industrial-strength security model designed to protect against both passive and active attacks. OpenVPN's security model is based on using SSL/TLS for session authentication and the IPSec ESP protocol for secure tunnel transport over UDP." -- http://openvpn.net/

IPSec's biggest problem is the complexity of the tunnel setup (IKE). The ESP protocol is pretty decent.

OpenVPN all the way! My server and client config files are each < 10 lines long. I manage my certificates with TinyCA. I think all of this is readily available via apt. Also has Windows and OSX clients.

Some software of that variety takes the approach of acting as an iSCSI device. So long as the OS has native iSCSI support, the application need not install its driver.

I'm considerably more worried about the impact on projects like OpenVPN.

Hamachi, available at http://www.hamachi.cc/ or
OpenVPN, available at http://openvpn.net/

The problem with PGP Phone is that it won't traverse NAT routers.

However, I understand that now there is other software for that. For example, Open VPN.

Any other suggestions?

I'm just going to link something: http://openvpn.net/

It's rather easy to make a darknet. I'll explain how to make one between you and your friends.

Create an encrypted partition on your disk.

Install OpenVPN (http://www.openvpn.net/ on the encrypted partition, and create your master key for the node there, and also create keys for your friends. Make sure to configure it so that your friends get large pieces of network space.

When your friends install their OpenVPN clients, they also do so on an encrypted partition. With the client config on the encrypted partition *and* the server config.

They may then give out accounts to their friends, and give away subnets from their subnet. The friends also need to put the configuration on an encrypted partition.. and so forth.

The beaty here is that if one node is compromised, the police will probably power off the machine ... and lose the config. If they infiltrate the network, they can only get their peers, not the entire network as the identity of the various nodes aren't announced more than the nodes wish. The IP's are not delegated by any central authority - but subnets are delegated and re-delegated.

Of course, such a network will suffer from low-bandwidth nodes, so you'll only wish to include high-bandwidth nodes towards the center. It could also be cool to run various routing protocols on top of this network.. and to let some of the core-friends be interlinked.

Go create a darknet today!

1) Install a second NIC or connect the modem directly to the server. Connection to the Internet should be though the server and connection to the Office should be though a VPN on the server.
2) Install a new IDE Hard drive in a 3.5" removable rack and tray. The drive should be than big enough for the operating system (Linux of course) and copies of some of the local desktop partitions. A telecommuter can shut down the server and bring in the HD during the day to resync and repair.
3) Install DHCP demon to allocate local IP addresses, DNS and gateway settings. If the desktops are network boot capable then install TFTP to remotely boot KNOPPIX via PXE. IF the desktop OS is constantly crashing, the user can select PXE boot, network KNOPPIX. The user can then be instructed over the phone to enable ssh server to allow remote repair and reimaging of the desktop partitions from copies on the local server.
4) Partition the desktops with as small as required C: ( or in the case of Linux the root ) partition for software. When software is install, use dd and netcat via live KNOPPIX to copy a snapshot of the partition to the server. You can allocate the remaining free space as a persistant partition where documents are stored. ( Consider hireing someone who knows how to customise Knoppix for your setup.)
5) Install/Enable VNC on all the platforms, but only allow incoming connections from the local server ( which is redirected over a SSH tunnel ).
6) For local backup, create share directories on the desktop accessable by the server. On the local server create loopback encrypted file systems, unmount and copy the images to the desktops shares in chunks, using redundantcy if enough space is available on the desktops. Checksum ( MD5 is enough ) each piece.
7) If the network load to the Office is takeing up all the available internet bandwidth or the connection is just too slow then install proxy servers on the local server and consider using a distributed filesystem ( OpenAFS is still the best ) .
8) If phone charges are eating into the budget, and the internet connection is good enough, then install Asterisk on the local server ( upgrade the server to a Celron 800Mhz or better ) and a card with enough FXS ports for each local user. Don't bother with software based phones/headsets. The phone will work when the desktop does not.
9) Set up a Linux server at the Office that operates as a thin client application server. Allow remote access though both FreeNX and VNC. Create login accounts and logins that operate as virtual meeting rooms, with multiple users logging in via VNC. Use VNCserver with a screen size of around 1000x600, that will operate via a VNC viewer on any 1024x768 desktop. Use phone based conference calling for voice -- it's a lot less hassle for the users
10) Add the ususal list of cross platform applications: Firefox, Thunderbird, Gaim, OpenOffice etc.

Do the open ten step and save yourself and your santity from all those hours driving from site to site.

When dealing with oppressive governments there are ways to play it safe. Even if you *THINK* you are playing by the rules why take a chance.

There was a very good concept someone came up with several years ago to build an encrypted network on top of the internet. Myself and a few others decided to put forth the time and resources needed to bring it to fruition. What we ended up with is anoNet.

Most of the info about the layout of the network is available at that link, but here is the "quick and dirty".

We took OpenVPN combined it with Quagga then used IANA reserved address space to build a fault tolerant, encrypted, anonymous network. The basic premis is that you only know the ips of your peers. On top of that you make sure that the people that you peer with are in countries that are not on the best of terms when it comes to cooperating with law enforcement. IE: China -> US. This network is _primarily_ used for two purposes: 1 - We are a self contained (for lack of a better word) Darknet. We have root DNS servers, a search engine (mnogosearch), email (webmail if someone doesn't want to run their own), IM (jabber), Web servers (with the ability to post anonymous content, and by anonymous, I mean anonymous even from the people INSIDE anoNet), FTP servers, IRC, News servers, Asterisk VOIP (although this is still in testing), Proxy servers, etc..etc.. We have taken great pains to re-implement the internet but with anonymity and encryption in mind. 2 - To provide users in countries that restrict internet access (China) the ability to browse (proxy) in a secure, safe manner.

I was going to throw a few common questions and answers in here but this post is long enough. If you want more info we have a nice Wiki setup to handle just about any questions you could have (but you have to connect to access it).

Bottom line if the people mentioned in this article had been using our mail relays / proxies this wouldn't be an issue right now. If people in (supposedly) less oppressive countries want to make a difference in the world, then donate a little time and bandwidth to the cause instead of blowing up countries.

SSL-Explorer appears fundamentally flawed to me. Two things immediately caught my eye on the site. One, they are *NOT* the first open source, SSL based VPN - see OpenVPN. Second, why in the HELL would I want to enable a "borrowed" (insecure) computer to access my VPN? If I am using a VPN to secure my internal network, why introduce insecurity like that?

I did think the other management features and uch were nice, but the lie about being a first and the flawed logic about security really turned me off to the project.

Build a lightweight VPN server into every router, such as Openvpn which uses TLS/HMAC and RSA keys. The router could easily generate and distribute the keys (over the wire) for wireless encapsulation.

So how do you limit access to the device?

The answer is to use RSA signed keys that limit connection on a per device basis similar to Openvpn TLS security TLS. http://openvpn.net/security.html

Seems simple to me.

OpenVPN is Free (in both senses), fairly fast, cross-platform, but most of all easy to setup. Tunnel all traffic through a single, CONFIGURABLE port. My IT department is also often inept & they're packet-shaper makes most VPN traffic crawl (as if it were P2P or something). We require fast remote control software to be run, so we put it on port 80 & watched the traffic finally fly along.

I've found that UltraVNC is the best VNC. Version 1.0.0 was released on 24 Jun 2005, but it is a quite advanced package. Be sure to install UltraVNC with the video driver, which is not included on Sourceforge.

AutoIt is by far the best open source software for automating Windows installs and other tasks in which the program pretends to be a user. There's an IDE with an Intellisense-like interface and a compiler.

I've heard that OpenVPN is the best software-based VPN, but I have not used it. There are hardware firewalls with VPNs; I suggest you stay away from Netgear's, which I have found to be quirky.

--
Bush lied, 100,000 died. J.C. said not to return violence with more violence.

http://openvpn.net/ It's an alternative. Difficult to get going but might help... It is like the Zion of the internet

Spin it however you like -- but read this.

OpenVPN's security model is quite strong -- as documented in the FAQ, it borrows heavily from preexisting (time-tested, heavily reviewed) protocols (not just SSL but ESP as well), and supports multiple layers of security (ie. "tls-auth", a pre-shared key authenticating all traffic; support for running unprivileged and within a chroot jail to prevent OS-level security breaches; etc). Further, the (limited region of) code which handles pre-authentication network traffic is heavily audited.

There has been analysis resulting in security vulnerabilities found; these have exclusively been related to misconfiguration, and even in those cases the daemon now spits out a warning when it detects such misuse. Certainly, OpenVPN hasn't garnered the level of direct review (as opposed to inderect review of components it borrows) that IPsec has -- but I'm confident in its security. Certainly, the other homegrown userspace VPNs all have serious issues -- but notably, those issues have by and large been pointed out, whereas OpenVPN's security model has had no serious flaws documented despite significant popularity.

OpenVPN has a number of other advantages as well -- plays nice with NAT, tunnels over almost any network, no interop issues (since there's just one implementation that runs anywhere), etc.

Spin it however you like -- but read this.

OpenVPN's security model is quite strong -- as documented in the FAQ, it borrows heavily from preexisting (time-tested, heavily reviewed) protocols (not just SSL but ESP as well), and supports multiple layers of security (ie. "tls-auth", a pre-shared key authenticating all traffic; support for running unprivileged and within a chroot jail to prevent OS-level security breaches; etc). Further, the (limited region of) code which handles pre-authentication network traffic is heavily audited.

There has been analysis resulting in security vulnerabilities found; these have exclusively been related to misconfiguration, and even in those cases the daemon now spits out a warning when it detects such misuse. Certainly, OpenVPN hasn't garnered the level of direct review (as opposed to inderect review of components it borrows) that IPsec has -- but I'm confident in its security. Certainly, the other homegrown userspace VPNs all have serious issues -- but notably, those issues have by and large been pointed out, whereas OpenVPN's security model has had no serious flaws documented despite significant popularity.

OpenVPN has a number of other advantages as well -- plays nice with NAT, tunnels over almost any network, no interop issues (since there's just one implementation that runs anywhere), etc.

http://openvpn.net/

I was worried there for a second.

Ok, no I wasn't.

Looking at tethereal capture while using the GWA showed that it doesn't compress HTTP request headers, and no encryption is used to talk to the GWA servers. It does send the X-Forwarded-For header so no real anonymizing is done.

I'll still prefer running encrypted OpenVPN tunnel over switched Ethernet to to a router that is connected to a Squid server that uses ISP proxy as cache_peer.

Also ping RTT to GWA European servers is ~73 ms (11 hops) while to ISP proxy ~19 ms (3 hops) that could count for something too.

One could use IPSec over wireless by purchasing a separate VPN router and then connecting the wireless access point to the WAN port of the VPN router. VPN client software could then be installed on all wireless client machines that will be connecting to that wireless access point. The VPN router itself could be configured to only allow LAN-side access to clients using IPSec with the proper key.

For OpenVPN, since I haven't seen any dedicated OpenVPN hardware myself (but I haven't tried looking), you would need a dedicated machine that has two network ports. One would be for wireless, the other for your LAN. You would then have to setup that machine to route packets to your LAN only if they use valid OpenVPN keys and also would have to configure each and every machine's copy of OpenVPN individually. One thing that I am unsure of is how much either IPSec or OpenVPN affect wireless's performance.

How about 1024-bit keys?

Currently we're experimenting with using an open WLAN with logged http/https access (for guests), and then OpenVPN for all the internal users. Same network, but the VPN users have good data encryption (better than if we used WEP) and thus are allowed to access many more services.

1) Install a OpenBSD after plugging in a wireless card that can be used in hostap mode.

2) Install OpenVPN (that has a nice Windows client), and generate server and client certificates. There are howto and scripts for this.

3) Configure the built-in OpenBSD packet filter to only accept connections to/from OpenVPN ports on the wireless NIC.

4) Show war drivers the finger.

Yes, but that are all point to point connections. I have got that set up already with my friends. Problem is that you won't get any routing, and you must trust each friend. It's a pain on your firewall and sockets setup as well.

What I need - and I think more people are interested in this - is something that established a virtual LAN. Now, VLAN is already another technology, so we might need another acronym. I would consider Open Virtual Private Lan, or OpenVPL for short (see below).

The biggest issues are probably the routing - e.g. broadcast packages - and management. You would also want to set it up as a LAN adapter as well (which requires insight in device driver development). You would probably want to start off with something like OpenVPN and add routing and management on top of it.

As you can see, I did a little thinking beforehand. Currently my private developments are all in Java unfortunately, so programming the TCP/IP stack in Linux is a bit too remote for me. This IS an interesting idea though, most of you will probably agree.

I suggest that you setup an encrypted VPN with openvpn.net on a host in a (more) free country. And then tunnel one or more IPs to china. You tunnel EVERYTHING, all traffic..

As I got one myself I know it works well. But I got it because my ISP refuses to give me 32 IPs with my own reverse, all ports open. And I dont want them to know what files I xfer over BitTorrent or other P2P.

1. Buy a cheap collocation server based in the US ($50-$100 per month).
2. Ask for an additional IP address (free).
2. Install OpenVPN on the server and your desktop (free).
3. Connect to your Chinese ISP and connect to your VPN.

All your outbound desktop traffic is now encrypted and passed through a UDP tunnel to your collocation server. The collocation server decrypts the traffic and passes it to the internet. Return traffic is re-encrypted and passed back to your desktop machine through the encrypted UDP tunnel. Looks just like traffic from corporate travelers connecting back to their home offices.

Extra bonus points for configuring your Linux firewall to encrypt all traffic from your home office and block any stray packets.

I have questions myself. What is the best way to form a VPN?

First, my universal advice: DON'T get in the habit of fixing remote systems for free. It is a huge time-sink & it would be better if you don't foster that dependence. I sometimes fix problems over email or in person for friends/family, but I also usually weasel some free beer out of the deal.

That being said, many have to remotely administer machines for OTHER reasons. Oftentimes, a shell is all that is needed & having OpenSSH is good enough. It is available for win32 too. This can also be used for port forwarding if other daemons are needed.

If you don't need SSH/SFTP & do need a secure connection, setup a VPN. OpenVPN is great:cross-platform, secure, and easy to install. IPSec is still the standard, but I don't bother with it unless I have to (like when my company would buy a hardware implementation). I try to avoid PPTP. It works OK on windows. Not so well on other platforms (poptop does a pretty fair job, though). It also believe it has some known (but, I again believe, still unexploited) security weaknesses.

You hooked on the GUI? I use VNC over VPN or stunnel. I don't really like remote desktop, but if you have to support it put RDesktop on your *nix box. FreeNX is, in many ways, better than both. I like it a lot, but I haven't used it under windows (it can be done & someone might have made it quick-and-easy, but I try to avoid supporting windows machines).