The purpose of this post is to describe, step by step, my attempt to set up an OpenVPN server on a Mikrotik RouterBOARD 750 and create a working tunnel from an outside machine (AWS EC2 Windows Server 2008 R2) to this OpenVPN server so that an SMB server on the local network can be accessed from said outside machine. The following diagram gives an overview of the setup:
That last step moves the new rule to the front of the chain; numbers ("5", "1") will likely be something else on your configuration. Firewall rule listing can be printed with the following command:
[admin@MikroTik] > /ip firewall filter print
Setup up a tunnel with OpenVPN client on Windows
After installing OpenVPN, create a config file for it. Here it's called "kahara.dyndns.org.ovpn":
client
dev tap
proto tcp
remote kahara.dyndns.org 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert ec2.crt
key ec2.key
verb 3
pull
auth-user-pass userpass.txt
Also, create a file called "userpass.txt" and put the following to it:
user1
pass1
Of course in an IRL situation one should use a real password. Make sure you copied the .crt and .key files over to the Windows machine, after which you can run OpenVPN client with:
Plan to use an in-house box to run a XenServer to host XP instances (I need multiple Windows desktops for "testing" purposes if anyone asks) had to be scrapped because the box was simply too loud and I couldn't get the wireless bridge to work – not that the latter would have helped anyway because like I said the box really is loud and relocating it anywhere inside our flat just wouldn't lower the noise level enough for it to not disturb sleep.
Which brings us here: launching a Windows Server 2008 R2 instance on Amazon EC2 and setting up Remote Desktop Services to enable multiple simultaneous client sessions. Below we can see Alice, Bob, Charlie and Dave each happily running their own Remote Desktop session at the same time:
The whole thing runs "tolerably" smoothly even on the severely memory-limited Micro Instace:
At $0.035 per hour this can be considered cheap. And, the server can be shut down when it's not needed in which case the only charge will be for the admittedly humonguos (35 gigabytes) Windows root partition. And of course those clients would need Client Access Licenses which adds a one time cost of roughly $100 per client. Now, to directly compare this kind of setup with having an actual physical server would indicate poor judgement as both have their strong and weak points but costs can be compared. So here we have an estimate of what the total cost of running a server like this for a three-year period would be, sans CALs:
On-Demand EC2
Reserved EC2
(1-year Contract)
Reserved EC2
(3-year Contract)
One-time costs
$0.00
$54.00
$82.00
Compute
$922.32
$421.56
$421.56
Storage (35 GB)
$138.60
$138.60
$138.60
I/O (10 IOPS)
$103.00
$103.00
$103.00
Transfer In (1 GB/m)
$3.60
$3.60
$3.60
Transfer Out (10 GB/m)
$48.60
$48.60
$48.60
Total Cost (Euros)
849.69 €
613.00 €
557.11 €
Per Month (Euros)
23.60 €
17.03 €
15.48 €
Source: http://calculator.s3.amazonaws.com/calc5.html
Then again, that 600 € would get you two HP Proliant MicroServers. Yet, then again, that price does not include Windows licenses and they would need a physical location, electricity, an Internet connection – an so on.
Small AP is small – and has a built-in antenna, too. I got two of these (for 19,90€ per piece – not A-link list price…) and set up a bridge so I could relocate my noisy Xen box from living room to kitchen to keep the box running 24/7 and sleep. (Turns out that in the end even this didn't help because the box remained loud enough to disturb sleep no matter what settings were selected in BIOS thermal management.) Initially it looked like the bridge worked just fine, except my testing revealed that the transmission speed was nowhere near the advertised "IEEE 802.11n (draft 2.0) / 150Mb":
XenCenter.iso 100% 44MB 1.5MB/s 00:29
After trying different cryptos from WPA2 to plain text and fiddling with various other settings I came to the conclusion that the slow speed was a feature of the device. Anyway, this was not really any kind of concern as I was more interested in latency, which was low enough (a few milliseconds). Put all this together and my opinion is that it's good enough for an access point that is about the size of a deck of cards and costs twenty euros.
What did turn out to be a problem is that at times the AP's would somehow manage get a broadcast storm going on, which of course took the wired network down with it very quickly. I wasn't really able to get to the root of this but from what I observed I can tell that the broadcast storm would happen even when one AP was connected to the primary wired segment and the AP at the other end was just "floating" there, with nothing connected to its' Ethernet ports. Also, while after enabling STP in the devices I could, using tcpdump, observe the STP config packets doing their thing and reconfiguring after for example dropping and then reconnecting either end of the bridge, this (STP) did nothing to prevent the broadcast storm from happening. I should also note for the record that I was using the "WDS", not "AP+WDS" mode.
Verdict: the devices just aren't suitable for this application, i.e. they are buggy and do not fully work as advertised but given their relatively compact size and ability to function as clients on a WLAN, I'll keep these.
As I haven't got an H264-capable camera to use as a test source (yet) I'm using the following GStreamer pipeline, adapted from videotestsrc documentation to generate an endless, mildly hypnotic low bitrate zone plate pattern wrapped in an MPEG transport stream. A clock is also shown so that when the stream is transcoded and/or segmented, it's easy to see how bad the lag is. Audio is not included but for example audiotestsrc could be plugged in the pipeline if necessary (although I won't be using audio in my app). VLC is used in the end of the command line to serve the stream over HTTP.
Well, it took "a while" but I finally got HTTP Live Streaming working with VLC. Downloading and compiling the latest from Videolan's Git repo was required ("1.2.0-git Twoflower" here). I might add that even though on the box that I did this I've compiled a lot of different programs (an Ubuntu installation that has gone through multiple dist-upgrades so it's a few years old and has a lot of packages (2344 atm) installed), quite a few external -dev packages relating to audio and video had to be apt-get'ed to make things work.
Below is the command to make VLC read a DVD and generate a segmented stream of H264 video and AAC audio to directory /var/www/html-video-stream/x/ on our local web server. In an IRL situation we would perhaps run the transcoder and segmenter instances on separate machines, or if we already had a suitable H264 stream source (like a camera) we could skip the transcoding step altogether.
QuickTime X (fanboys have had this since Snow Leopard) supports HTTP Live Streaming, so in order to show the above stream on a web page in Safari using the <video> tag, we can do the following:
Although I'm not sure if this will work in a situation where we attempt to feed H264 to clients that don't support HTTP Live Streaming, that is, we have an additional <source> element that points to a "regular" H264 HTTP stream. However, adding Ogg/Theora and WebM/VP8 support should not cause problems – I just haven't been able to make VLC output those (properly) yet. HTML5 video tag streaming support in different browsers is also one big question mark.
