Category: Internet

[sc:internet-category ]The last few years have seen a major change in the way we view networks and service providers around the globe.  Before the Internet became the commercial powerhouse it is today, BBS’s reigned as kings of online access.  In those bygone days, different serviced vied for prominence and one of the key factors was the modem speed they offered.

Even back then they competed for business on speed and reliability.  Competition worked well because the underlying transmission system (the traditional phone line) was the same for everyone and the service providers didn’t own it.  It had to be as phone providers are consider common carriers and they CAN NOT interfere with the communications.

Today we’ve gotten ourselves in to a real problem as our data networks have moved to transmission systems that are not classified as common carriers.  This combined with the underlying economic barriers to entry from new participants means we’ve provided the Internet service providers the perfect storm to act in an anti-competitive manner.

Business always try to maximize profits.  They do this by offering the least amount of service for the high cost they can get.  Competition on the other hand always tries to minimize profits but forcing business to offer more service for less cost.

And so we get to where we are today, in most markets there are two primary service providers, the traditional telephone company and the transitional cable company.  Neither really competing with each other but instead finding a happy mid ground and just matching each other step for step in the market.

They have managed to become the only two games in town because they piggybacked on their existing infrastructure to build out their data services and now the cost of a new entrant in to the market is too high to offer real competition.

When I moved to cable for the first time, my service was a fixed speed but unlimited usage.  It was what most people expect from a service like TV or Radio or their local telephone line.  You use it as much as you want for a fixed price.

Unlike telephone server, the internet really doesn’t have “long distance”.  But that hasn’t stop service providers from trying to bring that pricing model in to play.  The first step was bandwidth caps and bandwidth throttling.  Both primarily in an attempt to maximize profits, though there were short-term technical reasons as well.

Net Neutrality suddenly became a buzz word and an idea that many people rallied behind.  The idea being that a service provider shouldn’t discriminate against or alter  traffic for any reason.

And so the great “Net Neutrality” debate has been ongoing.  But it’s the same debate we’ve had before, just under a new name.

In the telcom space it’s the reason for the common carrier rules.

In the business space it’s the anti-competitive laws that have been enacted.

What it really comes down to is that we want all companies to have to compete for our business.  It’s the foundation of the free market idea.

When Rogers added bandwidth caps to my service they did so unilaterally.  At the same time Bell did.  I had NO choice about it.  Calling them didn’t help as they didn’t even offer an option of a service without a cap.

That’s a clear indication of a lack of competition.

In a competitive marketplace I would have had an option to go to another provider that supplied what I wanted.  I might have to pay more for it, but the option would have been there.

When we talk about net neutrality we really should be talking about anti-competitive practices.  This is the right discussion to have and for that there is a clear precedent set, regulation.

Different countries do it different ways, but they all regulate their telecom providers.  It makes perfect sense as the cost of the infrastructure to deliver service is just to great to build out multiple times.

It’s time to talk about how to regulate Internet service, either as a common carrier or some other way, but in a why they restricts the anti-competitive behaviour that all major service providers exhibit to one degree or another.

[sc:internet-category ]Ah Facebook, you great waste of time you, can you survive?

At least for me the answer is no.  More specifically, I’ve disabled my account and intend to delete it shortly.

What it comes down to is that Facebook doesn’t provide me with any value and comes at heavy cost.

The people I was friends with on Facebook, I saw in real life all the time.  The Facebook posts they created were just a repetition of things I had or would have talked to them about anyway.

Likewise Facebook’s ever creeping advertising and data gathering was become untenable to me.  The auto play video ads were the last straw and so I closed my account.

Twitter is much more useful to me and doesn’t (yet) hoard all my data as a way of advertising stuff I don’t want to me.

Now obviously I’m not the target demographic of Facebook so I doubt they’re miss me, but the feeling is mutual so I guess we parted as friends 😉

[sc:internet-category ]I’ve been using OpenVPN Access Server for quite a while, I set it up on port 8080 as I already had my Exchange server using port 443 on my router.  This wasn’t much of an issue as 8080 is pretty common and isn’t blocked very often.

However when I had to replace my DOCSIS cable modem recently I had to upgrade to the “wireless” router model and it used port 8080 as part of its administration interface.

Finding another common port that didn’t get blocked seemed like a challenge, so I decided to see if I could setup Apache as a reverse proxy in front of Exchange and OpenVPN.

Port Sharing

Turns out there is an even easier option.  OpenVPN supports a mode where it sits in front of another web server, any OpenVPN connections are handled by OpenVPN and everything else is just passed through to the web server.

This article, while short get’s to the point pretty quickly.

As I used a UCC SSL cert for my VPN/Web server I didn’t expect there to be any certificate issues with connections.

As I’m using the Access Server (AS) VM I didn’t want to mess around with the start scripts and config files, fortunately AS provides an option to add extra configuration lines through the web interface.  Simply go to “web admin->Advanced VPN->Additional OpenVPN Config Directives (Advanced)->Server Config Directives”, add the following line:

“port-share xxx.xxx.xxx.xxx 443”

This enables the port sharing mode and redirects the traffic to port 443 on the supplied IP address.  After restarting the services, connecting to the AS on port 443 brought up my web server instead of the AS, as expected.  One thing this does limit is that you can no longer access the AS web interface for downloading the client or profiles.  Not a big deal, but something to be aware of.

Another thing to be aware of, that isn’t document very well is that port sharing only works across UDP.  More to the point, you have to set AS to use TCP only, you cannot use the “both” setting or an error is generated during the service start-up and AS fails to run.

The next step was to connect to the VPN and test to make sure it still worked.  Using my laptop to connect from within my network failed, the connection would start to set up and then give a disconnect error.

Looking through the logs came up without much help, but I did notice the clock on the VPN servers was significantly out of sync (days of drift) so I reset them and tried again.  However still no connection.

Upgrading OpenVPN AS

My next thought was perhaps a bug in the version of OpenVPN I was using, I was a few versions behind with 1.8.3.  2.0.3 had been released a while ago so I decided to upgrade.

I had written a little upgrade script on the VPN servers which did the work for me but when I tried upgrading to 2.0.3 an error came back as the script could not find the 2.0.3 packages on the OpenVPN site.

Looking around turned up the problem pretty quickly, the AS VM I was using was based on Ubuntu 8, and in the version 2 release of AS, they dropped support for 8 and moved to 13.

To top it off, there is no upgrade path for the old AS to Ubuntu 13 so it means re-creating the AS VM’s from scratch.  This is not a huge deal and only took a few minutes, but I did run across one item that was an issue.

In the old AS, they provided a GUI interface for setting up the static IP address of the server, in Ubuntu 13 they didn’t both to bring this across and let you manually configure the interface by editing ‘/etc/networks/interfaces’.  The instructions are included on the AS download page but are a little miss leading.

Step three is:

Add the following lines using the template below: address 'ipAddr' netmask 'subnet' gateway 'gw' dns-nameservers 'dns1' 'dns2'

But that’s not quite true as it would lead you to believe that it is one line with all the options on it.  Instead you have to split each option on to its own line like so:

address 'ipAddr'
netmask 'subnet'
gateway 'gw'
dns-nameservers 'dns1' 'dns2'

Likewise, bring the interface down and then back up, does not work as documented.  You need to reboot the server to get it to work correctly.

I also changed the hostname, which they don’t document but is just a simple edit of /etc/hostname.

I then ported across my upgrade script which now looks like:

wget http://swupdate.openvpn.org/as/openvpn-as-$1-Ubuntu13.amd64.deb
dpkg -i openvpn-as-$1-Ubuntu13.amd64.deb
rm openvpn-as-$1-Ubuntu13.amd64.deb

Ran the apt-get to upgrade the OS and then upgraded to OpenVPN 2.0.3.

More Troubleshooting

After a reboot, same issue.  Connecting to the VPN failed with a disconnect each time.

Removing the port sharing option allowed the VPN to connect but of course didn’t pass through to the web server.

Trudging through the log files I found that OpenVPN was failing to detect the VPN connect and passing it through to my web server, which obvious would not recognize the connect.

My first though was that, since I have my OpenVPN setup in failover mode, that perhaps this was interfering with the port sharing.

I spun up another VM with AS and shutdown my current VPN servers and tried it as a single server instead.  No difference.

Searching the internet I found lots of people having issues with port sharing, but they had the opposite issue I did.  They’re VPN connections worked but pass through didn’t.

I have yet to find a solution to the problem and so I have instead configured OpenVPN to use port 943, the alternate HTTPS port which seems to be working fine.

Performance Tuning

Well almost fine.

The first time I connected remotely performance was terrible.  Dropped packets, connection drops, 1+ second ping times.

At first I though it might just be my connection at home or my current location, but when I took a look at the OpenVPN server at home, it was running very slowly as well.

When I upgraded to the new VM image for AS, I simply pulled the virtual disk and attached it to the existing VM’s I had on my server.  Turns out the memory requirement went up a little bit between the old and new AS.  I added some additional RAM to the VM’s, reboot and everything seemed much better.  The next day at my remove site performance was back to normal as well.

Summary

So what did I learn from this?

1. Well, port sharing is complex, finicky and apparently doesn’t work.
2. Upgrades from 1.x to 2.x aren’t simple with OpenVPN.
3. When building new VM’s, start from scratch 😉

Overall OpenVPN 2 doesn’t really bring much new to the table but it’s good to get the upgrade done and over with.

My last thought about the port sharing is that perhaps it’s just broken in AS.  I may, if I get some free time, try building a Ubuntu VM and installing OpenVPN from the source code to see if I can figure out what’s wrong with it.

However as port 943 seems to be working fine and it does give me the added benefit of having access to the web interface for OpenVPN, I don’t think I’ll change it at this point.