We have a network that is completely closed to the outside world. It needs to be. Problem is we need to remote into a server on this network once in a blue moon for diagnostics.

We've discussed ways to go about doing this and one method approved by some is to have a router that is powered by a device that would cut power when not in use but when needed we could phone into it and enable the power for temp access via a VPN.

What other alternative could we use that would totally isolate the network unless we needed to do 20 minutes of diags?

  • Is not clear if this need to be automated or if the device power on can be made by some user that is connected to the closed network or that can access its devices. Commented Jan 17, 2014 at 14:48

7 Answers 7


Don't do it. It's an isolated network for a reason, if you need access do it on site, not remotely so you can also monitor and shut down access locally. As I quote Adnan why you use isolated networks:

You don't isolate your network because you're afraid that someone will guess the right passwords. You're afraid of the human factor, the leakage of the passwords. You're afraid of the software itself, 0-day exploits*

Phoning in to power the router is an automated sequence. Either way, an advanced persistent threat is going to find and exploit this automated sequence to open what is in effect a backdoor to the network.

Adding a router wake-up system increases complexity of the system; it also exposes the network to the wild wild Internet. If the systems are not patched regularly (as is the usual case with isolated airgapped ménageries), there is strong possibility of missing a critical CVE or a zero-day and being pwned within 5-10 minutes of opening up for diagnostics.

  • I really like Port Knocking, it's a really nice idea, but in this case I'd strongly advise against that. This is just network isolation by obscurity. I don't think the OP's network is isolated because of opportunistic attacks by some scriptkiddie's scanner, most likely the network is isolated fearing a targeted attack.
    – Adi
    Commented May 6, 2013 at 17:41
  • actually it isn't if you have a high enough sequence of ports it's almost impossible to find the right combination. Imagine you would require 10 ports, you would have 65535^10 possibilities. You could also add rules which blacklist the IP after 10 or 20 failed knocking attempts. Commented May 6, 2013 at 17:43
  • 1
    Even of you require 100 ports, it's still a "password". Get it right, in the correct order, and you have access. The network isn't isolated. Not only that, it's a "password" that is stored on the server in plaintext.
    – Adi
    Commented May 6, 2013 at 17:55
  • yea but it doesn't open the network, it just gives you access to the SSH port, it doesn't allow you in you still need to authenticate to the system. Commented May 6, 2013 at 18:01
  • Exactly, it's just a second password (stored on the server in plaintext). The network is still exposed to the outside world, only a second password is added. I'm sure there are ways to configure VPN to require a second password (one that is not stored on the server in plaintext). Like I said, I like the technique (I haven't heard about it before) but it's almost completely useless in this case.
    – Adi
    Commented May 6, 2013 at 18:07

The standard "old-school" way of doing this kind of thing was to have a dial-up modem that was switched off all the time except when support was needed at which point a change record would be raised for it to be enabled, the remote support person would access the modem and then at the end of the work it would be switched off again.

The manual element (change control, physical power switch) provides you with some control and audit trail of why it's been used and reduces the risk of someone leaving the modem on (although there's always a risk that people get lazy, but then that's why we have auditors :) )

Modern equivalent could be to connect a cable to a router when a change request is raised for it and to have it pulled again when either the work was completed or after a set maximum time period has passed.

This of course requires that there is someone on-site who can do the cable connection/disconnection and also that there is a robust change control process in place. Of course none of this abrogates the requirement for the remote access solution to be secure ly set-up and configured. A risk with rarely used devices as this solution might be is that people forget to patch them...


You have a network that you want to keep isolated, but you're planning to reduce that level of isolation a little bit. I think the most important question you need to ask yourself at this juncture is: "Isolated from what?"

Let's say that you run an Internet-exposed VPN service that leads into this otherwise isolated network. That is likely to be a well-written piece of software that has seen tons of analysis. You can implement it with extensive safeguards including network filters, mandatory access control, alarms and audit trails. It is not extremely likely, in and of itself, to reduce your level of isolation.

Now let's look at the bigger picture. Who or what would be connecting to this hypothetical VPN? I would hazard that the answer is a multi-purpose workstation that runs a plethora of software. It browses the web, it opens email attachments, it runs software updates over the network. This machine is your adversary's best friend, a machine that is basically impossible to keep secure. I would bet that it has even been physically attached to the "isolated" network on occasion in the past. I would offer that it's this beast from which you desire to isolate your sensitive network.

Here's my point: Identify the threats you want to isolate from, and do it. Those threats are mostly Internet-bound attacks on the workstation(s) which will be used to remotely troubleshoot the sensitive network. I recommend a dedicated collection of notebook computers that are as minimal and hardened as your VPN server, to serve as the only authorized VPN clients.

I am amazed that many of the other answers think the problem is solved by secret knocks, keeping the remote access service disabled when not in use, etc. All of these tricks will be defeated the next time your admin opens a malicious PDF on his VPN client machine.


The answer depends on why the network is isolated and whether or not allowing external access is a problem. Your network must be compliant with whatever security standards and requirements are applicable with the network connected, and presumably you only disconnect it as an added layer of safety, not as a requirement.

Also, it's worth pointing out that if a network link is not explicitly for public, anonymous access, then it should be restricted and encrypted like a VPN, even though no technical requirement exists to otherwise demand it.

VPNs don't need to be as impossibly complex as IPSec. You can instead use something like SSH port forwarding. But I wouldn't throw away the idea of powering off the endpoint when not in use.


The remotely (or locally-)powered router approach makes sense, but creates a way to the inside that has to be protected.

The risks of that approach is that someone learns or leaks the information about the phone number - or maybe somebody calls in by mistake (or through wardialing, à la Wargames) - and the router is left powered.

So I'd say that

  • the router cannot be powered just by "a phone call". At the very least the device has to recognize the calling number(s) and/or the contents of a SMS with a password (that will have to be maintained and updated as all other passwords).
  • as an improvement of the above, the SMS might also specify the IP range to accept inbound connections from.
  • whatever happened has to be logged, and possibly checked against a registry or schedule of maintenance checks, so that an anomaly can be detected.
  • 20 minutes of call is not so big a load of data. The router might then also log and store the whole traffic, just in case.

With off-the-shelf components, a SMS dial-in system can be set up with the hardware equivalent of a PC, a SMS board/modem, a relay board, and a router, that has a list of allowed phone numbers. In this scenario the router would be powered on at all times (for firewall programming, maintenance, firmware updates and such routine checks), but the connection to the outside would be physically disconnected through the relay board. The workflow would be:

  • the SMS board receives a SMS
  • the "guardian" system analyzes the SMS and validates the sender number, the text contents and the requested IP range
  • the "guardian" system performs diagnostic checks on the router and builds and uploads the new route
  • the "guardian" system opens a SSH shell on the router interface
  • the relay board physically connects the router inbound data line
  • the user from the allowed IP range can now access the SSH login


  • the "guardian" system monitor the connection for timeouts, problems, and other anomalies. There should also be a maximum time after which the router is disconnected no matter what. And finally, when "disconnected", the guardian would check that the route is indeed physically down by interrogating the router diagnostics.

(If one wanted, the "guardian" system could even be made up of two independent systems, one with all of the above except the SSH server, the other acting as a firewall to the inside of the network. The first system could then sniff all of the traffic and there could be no way of accessing it except from a local console)

UPDATE Most of the above is (almost) readily available using scripting on an Android device offering an access point. A SMS from an approved source will activate the data link, the WiFi access point and a DynDNS update. Then an IP will become available to run a shell (and a VPN) on, albeit the data speed would be limited to that available to the telephone carrier.


Shelloid Virtual Private Transport (VPT) enables you to grant service access without yielding network access like VPNs. You can simply share the service when you need it and unshare it afterwards (once our APIs are in place you can write a cron job to do this automatically). VPT is open source (http://shelloid.org).

Disclaimer: I am the founder of Shelloid and lead the VPT project.


Some quick ideas.

  1. Idea with SMS or phone call with password is good.
  2. use virtual router instead of physical one. Virtual router could be started and stopped with no need to manage power supply.
  3. Use something like M2M connector from your secure network to some trusted cloud. So the data and commands should be pulled by isolated network from the could rather than pushed from outside.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .