Author: Martin

In my post from a couple of day ago on how to home-cloud-enable everyone, one of the important building blocks is an SSH tunnel from a server with a public IP address to the Owncloud server at home, i.e. not accessible directly from the Internet. I didn’t go into the details of how this works, promising to do that later. This is what this post is about.

So why is such a tunnel needed in the first place? Well, obviously, technically savvy users can of course configure port forwarding on their DSL or cable router to their Owncloud server but the average user just stares at you when you make the suggestion. Also, many alternative operators today don’t even give you public IP addresses anymore so even the technically savvy users are out of luck. So for a universal solution that will work behind any connection no matter how many NATs are put in the way, a different approach is required.

My solution to the problem is actually pretty simple once you think about it: What NATs and missing public IP addresses do is to prevent incoming traffic that is not the result of an outgoing connection establishment request. To get around this, my solution that I’ve been running from my own network at home for some time now over a cellular connection (!) 24/7 establishes an SSH tunnel from my Owncloud server to a machine on the Internet with a public IP address and tunnels the tcp port used for http (443) from that public machine through the SSH tunnel back home. If you think it’s complicated to set up you are mistaken, a single command is all it takes on the Owncloud server:

nohup sudo ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=2 -p 16999 -N -R 4711:localhost:443 ubuntu@ec2-54-23-112-96.eu-west-1.compute.amazonaws.com &

O.k. it’s a mouthful so here’s what it does: ‘nohup’ ensures that ssh connection stays up even when the shell window is closed. If not given, the ssh task dies when the shell task goes away. ‘sudo’ is required as tcp port 443 used for secure https requires root privileges to forward. The ‘ServerAliveInterval’ and ‘ServerAliveCountMax’ options ensure that a stale ssh tunnel gets removed quickly. The ‘-p 16999’ is there as I moved the ssh daemon on the remote server from port 22 to 16999 as otherwise there are to many automated attempts to ssh into my box from unfriendly bots. Not that that does any harm but it pollutes the logs. The ‘-N’ option suppresses a shell session to be established because I just need the tunnel. The ‘-R’ option is actually the core of the solution as it forwards the https tcp port 443 to the other end. Instead of using the same port on the other end, I chose to use a different one, 4711 in this example. This means that the server is accessible lateron via ‘https://www.mydomain.com:4711/owncloud’.  Next comes the username and url of the remove server. And finally the ‘&’ operator makes the command go to the background so I can close the shell window from which the command is started.

All of this begs the question, of course, which server I used on the Internet to connect to. Any Linux based server will do and there are lots of companies offering virtual servers by the hour. For my tests I chose to go with Amazon’s EC2 service as they offer a small Ubuntu based virtual server for free for a one year trial period. It’s a bit ironic, I am using a virtual server in the public cloud to keep my private data from the very same cloud. But while it is ironic it meets my needs as all data traffic to that server and through the SSH tunnel is encrypted end to end via HTTPS so nothing private ever ends up on that server. Perfect. Setting up an EC2 instance can be done in a couple of minutes if you are familiar with Ubuntu or any other Linux derivative and once done you can SSH into the new virtual instance, import or export the keys you need for the ssh tunnel the command above establishes and to set the firewall rules for that instance so port 16999 for ssh and 4711 for https is opened to the outside world.

And that’s pretty much it, there’s not even additional software that needs to be installed on the EC2 instance.

After all the mess with Heartbleed a few weeks ago and updating my servers I started thinking about the current state of security of my VPN gateway at home. So far, I've used a very old but rock solid Linksys WRT-54G with DD-WRT on it for providing Wi-Fi at home and VPN server functionality for when I'm roaming. But the latest DD-WRT version for that hardware is several years old and was fortunately made before the Heartbleed bug was introduced. So I was safe on that side. But for such a vital and security sensitive function I don't think it's a good idea to run such old software. So I decided to do something about it and started to look into how to set up an OpenVPN server on a platform that receives regular software updates. And nothing is better and cheaper for that than a Raspberry Pi.

Fortunately I always have a spare at home and after some trial and error I found these very good step-by-step introductions of how to setup up OpenVPN on a Raspberry Pi over at ReadWrite.com. If you take the advice seriously to type in the commands rather than to copy/paste them it's almost a no-brainer to do if you know your way around a bit in the Linux domain.

The second part of the instructions deals with setting up the client side on MacOS and Windows. Perhaps the OPVN configuration file is also usable on a Linux system but I decided to configure the OpenVPN client built into the Ubuntu network manager manually. The four screenshots below show how that is done. As some networks have trouble forwarding the VPN tunnel with a maximum packet size (MTU) of 1500 bytes I chose to limit packet size to 1200 bytes as you can see in the second screenshot.

Another thing that made the whole exercise worthwhile is that I have understood a lot better how OpenVPN uses the client and server certificates. I always assumed that it was enough to just remove a client certificate from the server to disallow a client establishing a VPN connection. Turns out that this is not correct. The OpenVPN server actually doesn't need the client certificate at all as it only looks if a certificate supplied by the client during connection establishment was signed with the certificate of the the certificate authority that is set up on the server as part of the OpenVPN installation. That was surprising. Therefore, revoking access rights to a client means that the client certificate has to be put on a local certificate revocation list the server checks before proceeding with the connection establishment. I'll have a follow up post to describe how that is done.

A final thought today is on processor load: My VDSL uplink at home limits my tunnel to a maximum speed of 5 Mbit/s. A download at this speed takes around 50% processor capacity on the Raspberry Pi independent of whether I'm using the NATed approach as decribed in the tutorial or simple routing betweeen the VPN tunnel and my network at home. At the moment I don't care as a faster backhaul is not in sight. But at some point I might need to revisit that.

Ever since I set up an Owncloud server at home, I've made my peace with cloud services, as my home has become my cloud and my data is where it belongs: With me, and with me only. While my personal needs for cloud services mainly focus on file sharing and calendar/address book synchronization there is a much wider spectrum of cloud applications that companies could benefit from such as secure communication with customers, project management and team interaction. And this is where Protonet comes in with their small on-site servers and cloud applications. I seldom plug companies and products on this blog but in this case I felt I had to make an exception. Even though their software doesn't seem to be open source their product makes the Internet and private data again what I think they should be: Decentralized and in the hands of those who own it. Best of luck to this startup, I wish you raving success! (via Heise news)

This is Protonet! from Protonet on Vimeo.

Two years ago I would not have speculated about UMTS being abandoned anytime soon. LTE was still relatively new and in Europe, UMTS was the main air interface technology for high speed mobile Internet access. But things have changed rapidly and LTE has taken over that role by storm. Today, most high-end and even mid-range smartphones come with LTE support and in many countries, LTE is deployed in a large coverage area and with bandwidths far surpassing UMTS. UMTS might still have the coverage edge for now but in some countries LTE is available in many rural areas where UMTS is not due to it's use of the 800 MHz digital dividend frequency band. All of this makes me wonder if the many new UMTS features that were standardized in 3GPP Release 8 to 12 will ever be used in live networks!?

Those that I can think of that would provide some value for example are a faster high speed uplink beyond the two to four Mbit/s that can be observed today, putting the slow FACH on a common E-DCH and lots of other small enhancements on the protocol layer to make the system more efficient and to have more users active per base station simultaneously. But with LTE going strong I have my doubts if the time and effort will be spent. After all, network traffic shifts towards LTE and UMTS is rapidly becoming the fallback solution in the areas where LTE is not (yet) available and of course for simultaneous voice and data during CS-Fallback while VoLTE keeps having teething problems.

So I wouldn't be surprised if in another two years LTE coverage might have reached the same coverage level as UMTS and the GSM/UMTS-only legacy device pool has shrunken considerably. Perhaps even VoLTE has made it into the real world by then and can really serve as a circuit switched voice replacement. But VoLTE has been in the making for so long, so I'd say this is the big unknown but a must have for any strategy to ramp down UMTS, as falling back to GSM for a voice call and then not having Internet access during the call is just out of the question.

It doesn't happen very often but every now and then I need to upload a really big file to my Owncloud server. And by really big I mean > 1 GB. That's a bit of an issue as the default Owncloud settings limit the file size to around 500 MB. In the past I tried a couple of times to increase the file size limitation with mixed success. When I recently had a bit more time on my hands, however, I investigated a bit further and managed to push the file size limit on my NUC based Owncloud beyond the biggest file I had at hand, 1.6 GB. So here are the values I changed:

In /var/www/owncloud/.htaccess:

php_value upload_max_filesize 3000M
php_value post_max_size 3000M
php_value memory_limit 3000M

In /etc/php5/apache2/php.ini:

max_input_time = 360   –> default value was 60 seconds which is too short to upload large files
post_max_size = 3000M  (might be overridden by the value in .htaccess)
upload_max_filesize = 3000M (might be overridden by the value in .htaccess)

And that's it, after a 'sudo service apache2 restart' large file uploads work as they should. For further details see this post on the Owncloud forum.

 

If you are in the business of analyzing UMTS network traces for development, debugging or operational reasons and ever wondered how to find out if a speech call was established as wideband or narrowband or if the codec was changed at some point during the call, I've got an interesting tip for you today that I was recently shown myself: Have a look at the

nas-Synchronisation-Indicator

information element in the RadioBearerSetup or RadioBearerReconfiguration messages of a call. It's quite at the top of the message in RabInfo section so it can be found quickly and the 4 bits of the IE describe the speech codec the MSC wants the mobile device to use for the call:

Narrowband: 1010 –> UMTS AMR-WB (see 3GPP 26.103, Table 4.2)
Wideband:     0110 –> UMTS AMR2 (i.e. narrowband)

Apart from the table in 3GPP 36.103, TS 24.008 gives some more details:

The ME shall activate the codec type received in the NAS Synchronisation Indicator IE.

The NAS Synchronisation Indicator IE shall be coded as the 4 least significant bits of the selected codec type (CoID) defined in 3GPP TS 26.103 [83], subclause 6.3.

 

A few days ago the German infrastructure regulator (BNetzA) has published its yearly report for 2013. Like every year it contains very interesting information that give a lot of insight, especially when comparing the numbers to previous years. For the moment I've only seen the German version but at some point I'm sure there'll also be an English translation. Here are some of the noteworthy things described in more detail in the report:

Voice and SMS

• The volume of mobile originated voice calls has reached 100 billion minutes in 2013, up by one billion from the year before.

• The volume of fixed line calls continues to decline. A total of 169 billion minutes were recorded and out of that, international voice calls accounted for 14%. That's actually surprisingly high for me but shows that the time when nations in Europe were islands is long gone. What I didn't find in the report was the number of international voice minutes from mobile. Due to ridiculously high pricing it's perhaps not even measurable in the percentage range!?

• For the first time ever, the number of SMS messages sent has fallen. Quite significantly, actually, from 58.9 billion down to 37.9 billion. Quite a steep decline and perhaps similar to what we've seen in Spain a year earlier. WhatsApp and Co. are showing a rather sudden effect.

Data Traffic Volumes

• The report contains information about fixed and mobile data volume over the year. In fixed line networks, 8 billion GB (8 million TB) of IP traffic was transported (not counting the incumbent's IPTV offer, see page 75 in the report). That amounts to an average of 22 GB per household per month. The 8 billion GB of 2013 compare to 4.3 billion GB in 2012 and 3.7 billion GB in 2011. Quite an incredible and sudden increase compared to the previous years.

• On the mobile side, 267 million GB (=0.267 billion GB) were transferred, i.e. only 1/30 of the fixed line data volume. The YoY rise was 70% and thus the rise was higher than the 56% and 53% in the previous two years. I wonder how much that has to do with network operators offering LTE as fixed line alternative in rural areas where ADSL is not available.

Revenues, Employment and Investment

• Revenues: There's been a slight decline, about 50/50 share between fixed and wireless in the order of 25 billion Euros each in 2013.

• Number of employees in the telecom sector: The downward trend continues, down by 3000 to 170.000 (compared to 230.000 ten years ago).

• Infrastructure Investments: 6.4 billion Euros, about the same as in the previous 5 years and somewhat less than the 7.1 and 7.2 billion Euros that were spend in 2007 and 2008. Keep this in mind next time you hear a telecom exec complain about rising or neck breaking investment costs.

 

After recently reporting about the current state of LTE carrier aggregation the technology circus has moved on again and hype is building up aground aggregating 3 component carriers in three different bands. Here's a report over at Lightreading that SK Telecom in Korea is undertaking first preparations on the network side for aggregating spectrum in three different bands (800 MHz (band ?), 1800 MHz (band 3), 2100 MHz (probably band 1)) for a total bandwidth of 40 MHz.

As there are only few devices and networks out in the wild so far that bundle two component carriers (such as AT&T aggregating 10 MHz and 5 MHz in two different bands) I don't expect to see devices soon that support reception on three different bands simultaneously.But in any case an interesting development to see. Apart from a higher theoretical maximum throughput, 3 band carrier aggregation with such diverse bands cold potentially bring interesting benefits in scenarios where a user frequently moves indoors and outdoors and thus is sometimes better served on a higher or on a lower band. Sure, inter-frequency handovers can also do the trick, but perhaps there's an advantage with carrier aggregation as fewer break and make handovers are required.