There were two more topics that I really wanted to dig into with the Opengear ACM5004; the Cellular Router capabilities (after all, it has that in the name) and the Digital I/O ports. In this post then I’m going to going to attack the first of those, and configure the Call Home and cellular failover features together to ensure that I can always reach the ACM device even if I lose my LAN connection.
Cellular Connectivity
The Opengear ACM device is available with either of two radio options; the Verizon-capable CDMA radio or the AT&T/T-Mobile GPRS/UMTS radio. I opted for AT&T in this case, and while the configuration for Verizon may be very slightly different than for AT&T, the end result and functionality should be the same either way.
Installation of the SIM is simple, but requires a screwdriver (better than a paperclip, right?). There’s a small covered slot on the side of the unit; remove it and install the SIM.
It’s not obvious which way up the SIM should go into the slot, but as it only fits one way round, it only took a few moments to get right. Once the cover is replaced, the unit can be powered on.
Configuration
Configuration for the cellular modem takes place within the System->Dial settings, on the ‘Internal Cellular Modem’ tab, logically enough. Configuration amounted to enabling dial-out and typing in the APN, so looks something like this:
Everything else was left at default values, although the settings continue quite some way past the cropped image here. At this point, the cellular modem should try to connect to the cellular network. You can quickly check the status of the connection on the Status -> Statistics page, on the Cellular tab:
I highlighted two fields that are important. The first is the Network Status – this should confirm that all is well. I found some documentation saying that it should say “Available”, but I’ve found that my one says “Normal” and seems to be working just fine. The second field I highlighted is RSSI, which represents the signal strength. That’s something quite important to check, especially if you are hoping to get away with using only the supplied antenna. Opengear’s documentation also points to the WWAN light on top of the ACM5004 for handy visual feedback on signal strength:
- OFF = Low, (lower than -100 dBm)
- Blinking Slow = Low to Medium (-99 to -90 dBm)
- Blinking Fast = Medium to High (-89 to -70 dBm)
- ON = High (-69 dBm or higher)
So far, all is good. I can also go to the shell and check the interface status for the cellular dialer:
# ifconfig -a
dialout0 Link encap:Point-to-Point Protocol
inet addr:166.1.1.2 P-t-P:10.64.64.64 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:7 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
As you can see, the dialer has picked up a 166.x.x.x IP, is using PPP with a default next hop of 10.64.64.64 (a well-known next hop for AT&T PPP tunnels). So far, so good!
Failover Disabled
For initial testing, I left the failover settings in System->IP disabled. This was to ensure that the wireless connection would be activated and would stay up while I validated it. However, once I was sure that the wireless was working, I configured IP failover to use the cellular network only as a backup should the LAN connection fail, as that’s the scenario I wanted to test here:
The probe addresses are used as you’d expect – if the ACM5004 can’t ping those addresses, it assumes that the Ethernet has failed and brings up the cellular network. In fact it looks like it’s fairly essential that this is the case, as even when I pulled the Ethernet cable, the interface status shown by ‘ifconfig’ remained UP.
Cellular Network Problems
In theory at this point, I could try to ssh to 166.1.1.2 from my PC and connect to the Opengear. However, typical wireless carrier network architectures make that impossible. Here’s how most – though possibly not all – carriers provide connectivity:
The firewall, I would add, is not to protect your endpoint so much as it’s to protect the radio network from an attempted denial of service attack (think about it – a 100MB DoS attack is bad for most sites; now imagine what happens if you do that over the cellular network). Anyway, what this means is that because the firewall will block any attempted incoming connections to the Opengear, I have to make the ACM5004 initiate a connection outbound instead.
Opengear’s “Call Home” Feature
In an ideal world, Opengear would be very happy if you chose to manage their devices via one of their Central Management Servers (CMS) – either the CMS6100 appliance or the VCMS virtual appliance. The Call Home feature on the ACM5004 (and other Opengear products) configures the device to open an ssh (secure shell) connection outbound to the CMS so that it can be managed via that connection even if there’s a firewall in the way that would have prevented the CMS server contacting the end device (as in the wireless architecture diagram above).
I do not have a CMS or a VCMS instance with which to test this out, but handily enough there is mention of also being able to connect to a “Generic SSH Server”, or – in my eyes – any old linux server on my home network! The configuration parameters allow you to set up ssh port forwarding as part of that connection, which is perfect – I can bring up an ssh connection that tunnels, say, port 8888 on my linux server through ssh to port 22 on the Opengear ACM5004. That would mean I could ssh to the remote ACM by initiating a local ssh connection to port 8888 on the linux server. And in doing so, I am creating an emergency back door for connectivity to the ACM. You can configure multiple port forwards, but for this test I’m only going to forward ssh traffic.
Configuring Call Home
Once I’d figured it out and got it working, the requirements to set up Call Home were fairly straightforward. You’ll need:
- A server accessible via a public IP, running sshd
- sshd configured to allow port forwarding
- An account on that server for the ACM5004 to log into
- RSA keys generated for the account
The Server
Setting up the server was easy. I used one of my internal DNS servers that runs Ubuntu, and made sure that sshd was configured to allow port forwarding by adding this option to the file /etc/ssh/sshd_config:
AllowTcpForwarding yes
My internal network uses RFC1918 addressing, but it was relatively simple to configure TCP port forwarding on my Netscreen (which acts as the NAT gateway for my home network) to map port 2222 on the public IP through to the DNS server on port 22.
User Account
Setting up a new account was simple; I chose to call it ‘cms’, as that’s the default username the ACM5004 would use to talk to the CMS servers. Initially this is where I stopped, and when I tried to set up up Call Home, it was failing with the error “Failed to authorize public key for [email protected], check Password“. Eventually I figured out that I needed to generate the RSA keys for the cms user. That was fairly simple – log in as ‘cms’ (or su, or sudo, or whatever it is you prefer), create ~/.ssh/, then generate the keys:
$ mkdir ~/.ssh $ cd ~/.ssh $ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/cms/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/cms/.ssh/id_rsa. Your public key has been saved in /home/cms/.ssh/id_rsa.pub. The key fingerprint is: be:2e:15:aa:fb:2c:ad:68:6c:7a:b0:a0:ca:eb:c1:03 cms@ ubuntu.mydomain.com
Easy enough once you actually know you need to do it!
Configuring The ACM5004
In the Serial & Network -> Call Home page, choose to Add a new device, then configure the appropriate information:
In this instance I entered my public IP (1.2.3.4), the password for the user ‘cms’, the port I had set up to be forwarded to the ssh server on my firewall (2222), the username (cms), and then finally the port forwarding requirement – port 8888 on the remote server forwarded to port 22 on the ACM (127.0.0.1 – i.e. localhost). I applied this, and waited while it attempted to connect. When the page refreshed, the configuration was successful and my server was listed along with the port forwarding:
So now what?
Test The Connection
Back to my local unix server, and I’ll want to initiate an ssh connection to the unix server itself (i.e. localhost, or 127.0.0.1) on port 8888, and if we’re lucky that should be forwarded over the Call Home ssh session that was established, and connected to port 22 on the ACM5004 so that I can log in.
john@ubuntu:~$ ssh -p 8888 -l admin 127.0.0.1 The authenticity of host '[127.0.0.1]:8888 ([127.0.0.1]:8888)' can't be established. RSA key fingerprint is 52:12:2b:25:ed:a1:f4:25:13:6f:b1:fa:38:d6:f4:aa. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[127.0.0.1]:8888' (RSA) to the list of known hosts. Welcome to OpenGear2.mydomain.com Password: $
Bingo – we have a successful connection tunneled over the inbound ssh session, and I’ve been able to log in.
Now, at this time the Call Home is actually being established over the LAN because I enabled Failover, which disables cellular while the LAN is active. Thankfully I have a smart enough firewall to allow my LAN-sourced traffic to go through the firewall, hit the public IP on port 2222 on its own outside interface, and forward it back to the right destination (the linux server). At least this means that I’ll always have a Call Home session whether I’m on LAN or Cellular, which is handy. However, it also means I have failed to test cellular so far!
Testing Failover
My highly complex test plan involved pulling the Ethernet cable from the back of the ACM5004. Disappointingly, I waited a while after pulling it but I was unable to connect to the ACM through the Call Home connection. After some troubleshooting – not least checking the session logs on my firewall – I realized that the ACM was in fact attempting to connect via cellular, but the connection must be failing in some way. This was good on one level though, because I was able to confirm that cellular data was working as I could see the connection attempts.
Eventually it dawned on me that the previous ssh connection (and port forwarding) had not timed out, and – from the looks of it – would not do so for quite a while. In the end, I opted to try using ssh keepalives to detect a dropped peer, and configured this in the sshd_config file:
ClientAliveInterval 60 ClientAliveCountMax 3
As far as I can tell, this did the trick. After I set the LAN connection back up again, I was able to failover once more to cellular, and this time after about 5 minutes I saw the old ssh connection drop, and shortly afterwards a new ssh connection establish over the cellular network.
Another quick test, and I was ssh’d into the ACM5004 over the cellular network. It was, of course, laggy – but that’s the nature of things. I happen to know that my ACM’s cellular connection (located in Atlanta) was being routed through Chicago, so I had a ~1200 mile round trip added to my communications in addition to the latency of the cellular radio itself. Still, I was connected, and that’s what counts. Success!
Failing back saw a similar delay – 5-10 minutes before the Call Home connection failed back to the LAN path. That may be for a few reasons, and led me to ask a few questions (the answers to which may be out there, but I haven’t found them yet):
- How often are the failover probe IPs polled? How many probe failures trigger activation of the cellular backup?
- How often does Call Home retry if it fails for some reason? I believe it backs off quite aggressively, which may lead to additional delay if sessions aren’t cleared quickly on the server side.
- How quickly after the Ethernet comes back up is the cellular dialer disabled again?
- Are these timers now (or will they be in the future) tweakable from the GUI?
Conclusions
Opengear’s cellular modem backup option appears to work. Additionally, Call Home to a generic ssh server also works, and I was therefore able to failover between LAN and Cellular networks and connect to the ACM5004 even when the LAN was down and the cellular connection had a firewall in the way.
This was another case where a single “HOWTO” document that pulled together all the necessary information would have been really useful (and maybe this post will stand in place of that for the moment). I found myself bouncing around the Opengear FAQs trying to piece together enough information to make this particular solution work. Knowing that I’d have to generate RSA keys for the ‘cms’ user account on the ssh server would have been handy. However, despite a few bumps in the road most of the process was easy, and not all of issues were Opengear’s responsibility!
Sadly, the SIM I have does not have SMS capability, otherwise I’d love to try SMS triggers and report back on that. Still, cellular data seems to works well enough despite the inherent lag, and it’s very useful that I can use a generic unix server to terminate a Call Home session – Opengear has resisted the natural temptation to try and make it a proprietary connection so that you are forced to buy their CMS. For that alone, I applaud them.
Disclosure
Opengear was a paid presenter at Networking Field Day 4, and while I received no compensation for my attendance at this event, my travel, accommodation and meals were provided. I was explicitly not required or obligated to blog, tweet, or otherwise write about or endorse the sponsors, but if I choose to do so I am free to give my honest opinions about the vendors and their products, whether positive or negative. Opengear provided me with an entry-level console management device (ACM5004-G), and more recently an ACM5004-G-E, both of which I am using as test hardware to create the content for these posts. I mentioned a while back on Twitter that I wouldn’t be testing the cellular option on the ACM, as I didn’t have a suitable data SIM available. Shortly after that, the nice folks at Opengear got in touch with me and have lent me a SIM with which to do a little testing; again this has been done with no obligation, and my opinions remain my own.
Please see my Disclosures page for more information.
Leave a Reply