Internet in a box

I have finished my cruise now, which was mostly holiday, but also some work. I did some training for my mates (mainly in C coding) and we did various coding as well (there were a few sea days). But now I am back I am making up the next version of my "internet in a box" that I take on cruises like this. I'm doing it now whilst I remember the last cruise in detail, even though my next cruise is some way off.

OK, that is not it - we have one of those, and it would be really cool if I could fit the bits in that box, but at present is is a tad larger... More like this...

So, what's in the box?

• FireBrick FB2900
• Aruba 501
• 2x Aruba AP-303H
• 3x PoE injectors
• 1x 4 way power strip
• Magic tape to hold it all in place

This is obviously somewhat overkill, so worth some explanation...

FireBrick FB2900

The FireBrick is a "swiss army knife" of network contraptions. It does a lot.

When you are trying to use internet on a ship you have a challenging, even hostile, environment. There are blocked ports and protocols, 700ms round trip latency (or randomly much more), packet loss at various levels, strange MTU issues, and seriously messing with TCP packets (acceleration). This can all change on the fly as you travel (the Panama trip was especially complicated).

To be clear, this is not stealing internet service - it is expensive and we pay for the premium, unlimited, steaming package for multiple devices. This does allow connection of devices that do not have WiFi or have a browser.

Whenever I take a FireBrick on a cruise we find new ways to improve it. This can be changes to handle high latency, or new features to handle some of the limitations. Even simple higher level protocols can struggle with the very high latency and low level packet loss. A lot of new features are the result of testing in this harsh environment and have benefitted the FireBrick code. Not sure I can expense my cruises as R&D just yet though, shame.

So, this alone, is one of the reasons for the crazy set up. The FireBrick can do various VPNs, UDP over faked TCP, TCP relaying, all sorts.

The main objective is to connect to the ship internet (WiFi) and provide internet to laptop or apple TV. For the apple TV to work in any expected way without regional blocks, it needs a working UK IP address in some way, and the FireBrick can do that.

The FireBrick can also monitor the connection in various ways and fall back, even to simple NAT over the ship's WiFi as last resort, and report status on an LED to make it obvious. If ever I fit this in one of those black boxes, the LED will not just blink red :-)

Aruba 501

This is a rather nice WiFi client. It connects to the WiFi and can do MAC cloning, where it will associate using the same MAC address the FireBrick is using. We found that the WiFi on ship filters other MAC addresses, and even locks down the connection after a little while if it sees more than one MAC. We were changing MACs every day until we managed to lock it down to no see any others.

Aruba AP-303H

Having connected to the Internet, and set up a VPN, we then provide internet over WiFi. It can be done with cables, but WiFi is fine and not as messy or such a trip hazzard. Previously I took a larger ceiling mount AP, but that gets hot, especially if not ceiling mounted. So this time I have smaller, and lower power, AP-303H units. I also have two, one facing each way, so the box can go in the corridor. Ships have big metal walls which make WiFi tricky. Even so, I am taking some 10m ethernet cables to allow me to place the APs to cover the whole cabin if necessary.

We actually had to set a hidden SSID, as we found that in at least one port we were seeing de-auth attacks. Interestingly this was not happening once we changed to hidden SSID. Even with the metal walls, we often see people running personal hotspots when in port, so it may be an attempt to stop that (AFAIK not legal to de-auth people like that, but who knows on a ship).

Update: Having two APs powered by PoE means I have more options - running a cable to place one, or both, APs, in more suitable locations in the cabin if they don't work in the box.

PoE injectors

This is another change from previous cruise - the last couple of times I took a nice 8 port Aruba PoE switch, which is quite big and has a big chunky power supply. This time I have three small PoE injectors which take a lot less space overall. There are some multiple port in-line PoE injectors which may be a good alternative to consider, but even with just one such unit I still need a power strip to power it and the FireBrick.

The AP-303H includes a switch, so if I need more Ethernet ports, they can provide them, so the bigger switch was not needed.

Power strip

The three PoE injectors and FireBrick mean a 4 way power strip - though I am considering making a lead with daisy chained C13 plugs and a C8 all on one lead perhaps. However, the 4 way strip fits fine. One option may be an IEC socket in the side of the Peli case so it can be closed. It looks like the whole lot is not generating enough heat for that to be an issue, but something to test.

Update: One idea is to use a 4 way IEC distribution board instead, which may well take less space.

Spare space

The whole box, even with all those bits taped in to place, has a lot of space. In fact I can pack my laptop, charger, mouse, mat, Apple TV, spare cables, phone charger, and so on, all in the one case. This means all of the tech in one small Peli case which then just sits in the corridor to provide "internet in a box".

Why?

Update: This allows me to bypass much of the hostile environment, and have clean Internet access on my own IP addresses. It even allows me to have a standard VoIP phone on the table in the cabin if I want. It allows devices that could not connect to ship's WiFi on their own (I had some of my IoT stuff on it). It is not trying to be the cheapest, or even the smallest (though I am trying to make it smaller). It mainly allows testing and development of the FireBrick in such an environment, and it is fun (for me), even if it is overkill.

Update

A few more pictures. I decided to go for an IEC distribution panel inside, and fit connectors to the case itself, and add a 3G/4G dongle.

P.P.S. Using V2.0.0.1-Aruba501-B0013 on the Aruba 501 was Crashy McCrashFace, but V1.0.1.3-HP501-B0012 seems to be stable.

FB2900 and Let's Encrypt

Well, the FB2900 is out!

The retail prices are lower than the old FB2700, £500+VAT for base, and £550+VAT for fully loaded with £35+VAT for rack mount kit. We should have the DC powered models available soon.

We have gone for lower prices to encourage more take up in the SME market. It is a bit of a gamble, but this is a really good product - not just a gateway router handling multiple ISPs, but even a VoIP switch / PABX. Perfect for most small businesses and even some large businesses.

The delay, for a week or so, was down to wanting to ensure https was working - this meant a lot of loading Windows VMs and testing on all sorts of different browsers. It needs manual loading of key pair and cert but it works well. I am really impressed with the work of my colleague, Cliff, on this, as the end result is just as fast to use as http. Very impressed.

It is timely as safari, and I am sure others, are now getting quite pushy on sending any form to a site not using https.

But we have said we expect to release more new code soon. The FireBrick s/w has always been free, and we have ensured the older models FB2500, FB2700 and the FB6000 series, all have the update for https now. But the next code issue should make it a lot cooler.

First off, I am planning some simple self signed stuff so you can use https before setting anything up. This is a bit naff, but every other idea we have come up with has flaws, and it is what everyone else does. The key thing is that it stops passive snooping as a threat, but not not proper security.

You need a proper key pair, and certificate, to do https without warnings. The FB2900 have a key pair loaded individually as part of the production process which means we just need a certificate. The FB2500, FB2700 and FB6000 series will need a key pair loading. This is partly because we are not yet confident we can make a "good" key pair. We are very cautious when it comes to security, and this is an area that has gone wrong for others, so we want to be careful. When we are happy we can, we will, but whilst FB2900 has a hardware true random number generator, the older models do not, so it will not really help for non FB2900s.

But even with a key pair loaded, which is not hard, you need a certificate. This is where we plan to do way better than most embedded systems. We plan to use ACME with Let's Encrypt as standard!

So the idea is simple, tell the FireBrick its public hostname (and if not an FB2900 then load a key pair) and it will make a CSR, apply for a certificate from Let's Encrypt and install it and renew it as needed. Proper working https with no warnings and no faffing about renewing things. That's the plan.

The same certificates and keys can then be used for IPsec, obviously.

It is not that easy as it is aimed more at a traditional machine / server, and not an embedded device, but I believe we should be able to do that within a few weeks and have a new s/w release.

In the mean time, do enjoy the new s/w release for the whole range - which will be a formal release shortly after beta testers are done with it.

P.S. (18th April) All going well, and we expect to issue alpha code any day. Test bricks with just adding public host name working on https 4 seconds later. This is "fun" coding!

FB2900

Well, Cliff has been working hard on this, and we are expecting to start shipping any day.

This is indeed a FireBrick https access from an iPhone!

Anyone who has alpha code access on their FireBrick (FB2500, FB2700 or FB6000 series) can test https now.

You need to install a key pair and certificate, which could be self signed or (as per my testing) a Let's Encrypt one matching the hostname of my test FireBrick. The plan is that in the following release of code, the FB2900 will be able to do this automatically and use ACME to obtain and maintain a certificate to make it easy.

Email the firebrick testers mailing list with any feedback.

If testing goes well over the next few days we'll be able to announce the FB2900 details and launch.

FireBrick FB2900

FireBricks have been around nearly two decades now, before things like https were a consideration. Whilst we have embraced IPv6 as part of the design of the current FireBricks from the start, https was not top of the list. Why? Well, the FireBrick web interface is usually only for management of the FireBrick. The idea is that most customers would have it is on a separate management LAN, or locally connected, of even behind an IPsec tunnel (which the FireBrick can do), so https was not actually needed that much.

However, https is more and more a thing and becoming so much the normal way of working (with browsers warning if not https even), so we are including it in the new FB2900, and the existing FB2500, FB2700, and FB6000 series as a free software upgrade.

In fact, working https, with an SSL Labs score of at least "A", is pretty much the reason for the current delay on the FB2900 launch. We have finally sorted the other issues which had added months and months to the launch of the FB2900, but as https is almost ready we are going to ensure the launch has https. It is literally a matter of days away - I have working https on my test FireBrick (SSL labs score "B") even now, thanks to hard work of my colleague Cliff.

We then follow on with ssh, and the plan is ACME support to use Let's Encrypt to make https really easy to install - point a domain/hostname at the brick's IP and bingo, it will be properly certified https. It will still have all of the access controls, but with caveats for ACME certificate renewals. The ACME Let's Encrypt certificates will help with IPsec configurations as well.

Sadly, one of the things we would have loved to do is impossible. We wanted a brick "out of the box" to work with https with no warnings. We could maybe include a cert for my.firebrick.uk or some variant to do this, but any means by which a FireBrick has a private key in the code would mean someone could get a FireBrick and JTAG or some such to extract it from the flash. It would allow that key to be extracted and misused. The only real answer will be for a FireBrick to have a unique key pair and obtain a signed certificate by ACME, or similar, and that can only happen after it has a public hostname and internet connection. So the initial set up will have to be over http or with a "security exception" to talk https. Typically this is literally a laptop connected to the FireBrick, so either is acceptable, but a shame no way to avoid that. It would be interesting to consider the ways embedded devices could solve that within an https and certificate framework one day (TTL 1 and tied to MAC address or something?).

So, FB2900 really close now... Many boxes on the shelves ready to ship... Watch this space!

P.S. I won't bore you with the days of work on the outer packaging shipping label featured in the image above. Lots of svg, barcodes, and postscript and stuff with UPCs and things. All very boring I am sure... :-)

P.P.S. We may forego the "A" rating at launch for the working on all main browsers and not add more delay.

P.P.P.S testers that can load "alpha" releases should hopefully have access to play with this in next day or so.