Capcom and I go way back. When I say way back, I mean in the good ol’ days with the original arcade version of Ghosts and Goblins (circa 1985). Throughout the years, I’ve played Megaman, Bionic Commando, Resident Evil and others. However, none of these games captured my attention (and my wallet) more than Street Fighter did.

Today, I found out that Capcom is going to release two Street Fighter games to XBLA later this year. Super Street Figther II Turbo HD Remix and Super Puzzle Fighter II Turbo are going to be given a full makeover by the people at UDON studios. All the characters, the character select screens, and the backgrounds are going do be redone pixel-for-pixel.

This is pretty exciting, I loved both of these games and spent countless hours playing each of them. It looks like I’m about to go in for round 3 once these games are released. Oh yeah, this means that I finally have to get off my butt and get an XBOX 360. Now, I wonder if they make an arcade like controller – I could never play Street Fighter on a game pad very well.

For more information, head on over to this article on Joystiq.com.

This weekend, after copious amounts of reading, preparing, rigorous testing, and plenty of cursing, I decided that I was prepared enough to replace the 75 lb steel server that was playing the role of my Exchange Server.

The new system (codenamed warhawk) is faster, smaller, and a whole lot quieter but above and beyond it’s also running on a completely different platform. Gone are the days of Exchange Server on Windows – this new system is running Debian Etch (now stable), Postfix, Cyrus IMAP with a dose of SpamAssassin and Razor for good measure.

All in all, I think it went pretty well. I did have a little problem migrating some of my mailboxes over to the new server, but once I found what the issue was it’s been smooth sailing ever since.

Two things saved my hide during the whole process. First off, The Book of Postfix is an invaluable resource for understanding everything that there is to know about Postfix. I don’t think I would have even attempted this project without this book at my side. The second thing is documentation; my own. During testing, I wrote down every little command that I ran to make the server run. Without this, things would have easily been hopeless.

I’m pretty happy with the end result. Postfix runs like a dream as an MTA and the multitude of anti-spam features are a breath of fresh air. I’m amazed at how much spam I stop at “SMTP time” without it ever hitting my inbox.

What spam does make it through gets whacked by the tag-team of SpamAssassin and Vipul’s Razor. SpamAssassin neatly appends the string “SPAM” to the existing subject line, wraps up the message in an attachment and then attaches it to a new report email detailing why it marked it as spam.

After completing my previous project (read The Warhawk Flies), I embarked on my next project; remote access to my network.

Previously, I was using Windows 2000’s RRAS to create a PPTP VPN and it served me well for years.

Eventually, all good things come to an end and so it was with that VPN server. Windows 2000 is already in extended support with Microsoft and soon it won’t be supported at all. Seeing the writing on the wall, I decided that this was the time to retire it and move onto something else.

I decided to set my sights on OpenVPN, a free, open-source “”Secure Sockets Layer">SSL" based VPN.

Instead PPTP or IPSec, OpenVPN makes use of public key cryptography (you know the same thing that your bank uses to secure your transactions over the web) via the already established OpenSSL libraries to encrypt the data that is being sent to and from the remote host and the VPN server.

I’m in the final testing phases of the implementation and what I’ve seen isn’t encouraging. Using Debian Linux as my server, installing and configuring OpenVPN was simpler than I thought.

The initial connection to the server was simpler than I thought too. Unfortunately, this initial connection only allows me to communicate to the server without being able to communicate to the machines behind it. In order to do that, I instruct the server to “push” some static routes to the remote machine.

This should work much like my old PPTP implementation did (read How to Setup a PPTP Encrypted Wireless Network). I’m not sure what causes it, but as soon as the server instructs the client to add the static routes to its routing table, the log starts to fill up with error messages.

The error message reads: “write UDPv4 [ ]: No buffer space available (code=55)”

More disturbing than the log filling with errors is the performance of my client machine (MacBook 1.83 Intel Core 2 Duo with 1 GB of memory using Tunnelblick as the OpenVPN client) after the errors start appearing.

After 30 seconds to a minute, the CPU will start to go haywire and the fans will turn on to try to prevent the CPU from overheating. My normally cool CPU, which runs at ~50 degrees celsisus (122 degrees F), will jump to the ~78 degree celsius (172 degress F!!) range. I haven’t stood around to see what happens if I let things run. Usually when I hit this point, I usually just reboot the Macbook (stopping the Tunneblick process didn’t seem to do anything).

The ultimate test comes tomorrow when I attempt to connect to the server from outside my own network. We’ll see what happens.

Things are looking up on the OpenVPN front. I’ve successfully connect both my MacBook and my Vista machine to it from a remote network.

I also understand why my MacBook started to overheat. More on that at the end of the post.

A normal PPTP VPN works by assigning your computer an IP address on the remote LAN.

OpenVPN has two modes of operation; brigding mode and routing mode. Bridging mode works exactly like a standard PPTP VPN server. It assigns an IP address from the remote LAN to a virtual TUN adapter.

Routing mode is very different. Using routing mode, the server assigns a private, non-routable address to a virtual TAP adapter on both the client machine and the server machine. This address is not on the private network that the server resides on.

For example, let’s say that your server has an IP address of 192.168.1.2. Using your SOHO router you forward port 1194 (UDP) to the VPN server.

The TAP adapter created on the server, using the default configuration, would receive the IP address of 10.8.0.1 and the client machine would receive the address of 10.8.0.5.

At this time, a private tunnel has been created and you can communicate with the server and only the server. In order to participate on the local remote LAN (192.168.1.0/24) you have to alter the routing table on the client machine.

OpenVPN can alter the routing table for you by including in the client config file. What this does is route all information that is destined for the 192.168.1.0/24 network through the virtual TAP adapter (10.8.0.5).

If this wasn’t enough, you still can’t communicate to the remote LAN. You have to setup IP Forwarding on the OpenVPN server and setup a static route on the SOHO router that routes anything on 10.8.0.0/24 through 10.8.0.1.

Whew. Understandably, bridging mode is the easiest of the two. After this has been completed, you should be able to access machines on the remote LAN.

I haven’t really explained why my laptop was freaking out. I had an idea, but I didn’t confirm it until yesterday.

To simulate coming in from a remote network, I was using my MacBook wirelessly. My wireless network is behind its own router that is behind my SOHO router (see diagram of network).

The short of it is that in my client configuration, I was initially connecting to the OpenVPN server at 192.168.1.8 but then when the server pushed the routing information, that said to send all information destined to 192.168.1.0/24 down the VPN tunnel.

I essentially create a huge network loop. My poor MacBook never had a chance.

I can make it work the way the old configuration did, I just have to switch from routing mode to bridging mode.