Using Powershell and to Ease the Burden of WAN management

Imagine for a moment that you are an IT Professional charged with the care, feeding, and security of a classic Wide Area Network (WAN). Further, assume that, like any properly-designed WAN, your remote networks (whether MPLS or classic Hub-spoke) egress their internet connections directly, that is to say, internet traffic from remote networks isn’t back-hauled to your datacenter or HQ.

In such a scenario, you will need to have a list of each remote network’s public IP address and other pertinent details in order to manage routing and security at each branch. In my case, I needed up-to-date public IP address information in order to properly segment & report on internet traffic traversing our SSL/TLS proxy inspection service, Zscaler.

So how would you do this? An earlier version of myself, say 15 years ago, would respond this way:

I’d remote desktop to a node in each remote network, open up a browser window, and visit Then I’d carefully copy/paste the IP address details into my Excel document, and happy days! – Jeff, 15 years ago

Wrong answer, Jeff from 15 years ago! That’s bad practice, takes way too much time, involves using the cursed mouse, and is fraught with security risk because it involves browser use.

Fortunately, there is a much better, simpler, faster and more secure way to do this. Even better, it involves my favorite tool in the world, Powershell, as well as, a web service that blows out of the water.

Best of all, you can do it all without your hands ever leaving your keyboard. Check it out

Let’s use Powershell’s invoke-webrequest cmdlet to see what returns to us:

Nice! As you can see, returns to us an HTTP content-type of application/json, which stands for JavaScript Object Notation.

JSON, if you’re not familiar with it, is an open standard that has superseded-in practice- XML and other structured document standards. It’s in widespread use across the internet, and it’s really great for us Windows admins that feeds us a JSON response to our query. Why?

Because we’ve got Powershell to make it look pretty for us! We just need to pipe the results of the invoke-webrequest command into the handy convertfrom-json cmdlet. Voila!

This is great, now I’ve got high-quality IP Information on my workstation. So how do I scale this out to my remote WAN networks? how do I get the public IP address of my Lake Winnepesaukee branch office using Powershell?

Assuming you’ve got a Windows domain and have configured Windows Remote Management in a secure fashion, the way to do this is simple. Let’s use Powershell to tell a WIndows node at each branch to fetch us the public IP address it’s sitting behind, format it in a pretty way, and bring it back to my beautiful blue console. In fact, let’s do all the branches at once by using invoke-command:

Boom! That’s how we do it in 2017! It took less than 20 seconds to invoke our simple invoke-webrequest + convertfrom-json command across five remote hosts. No remote desktop needed….all of it done securely via secure WinRM which I’ve set up my nodes to listen for.

With these results in your console, it’d be trivially easy to dump out each WAN’s public IP information into a CSV, or, even better, create a new Excel spreadsheet using new-comobject and save/send the information from there.

Fixed Wireless is the WAN builder’s best friend

This is Joe. He's an American hero.
This is Joe. He’s an American hero.

Just how hard is it in 2015  to order & deploy a cheap commodity internet circuit to connect a remote office/branch office (ROBO) to the rest of your corporate WAN via the internet? ((Commodity = business class internet, something less reliable but orders of magnitude less expensive than a traditional private line, T1, or managed MPLS circuit. Commodity also means fat, dumb internet pipe, a product that cable internet companies consider an existential threat))

Pretty damned hard.

Why so difficult Jeff?!? you’re thinking. I stand-up tunnels and tear them down all day long, I route/switch in my sleep and verily I say unto you that my packets always find their way home, tags intact, whether on the WAN, between switch closets in the campus, or between nodes in the datacenter!

Verily they do indeed, and I salute you, you herder of stray packets!

It’s not that the technology connecting core to branch is hard or difficult, no, what I’m bitching about today is connecting the branch site to the internet in the first place.

It’s layer 1, stupid.

Truly, ordering internet service for a small or even medium-sized branch office is one of the most painful exercises in modern IT.

Here, let me show you:

  1. You Bing/Google various iterations of “Lake Winnepesaukah ISPs,” , “Punxatawney Packet Delivery,” , “Broadband Service in Topeka,” “Ethernet over Copper + Albuquerque,” “Business Cable Internet – Pompano Beach, FL” and such. Dismissing the spam URL results on Page 1-12, you eventually arrive at Comcast, Time Warner, or Charter nee Spectrum Business, or whatever little coax fiefdom has carved out a franchise at the edge of your business. You visit their website, click “Business” and fight your way through pop-ups and interstitials to a page that says it can verify service at your branch office’s address.
  2. Right, you think, I’ll just Tab-tab my way through this form, input my branch office address here, punch that green submit button there, and get these nasty Layer 1 bits out of the way. But this isn’t the old days of 2009 when you could order a circuit online or at least verify service…oh no, no sir, this is the future…this is 2015. In 2015, you see, the Cable providers demand audience with you, so that they can add value.
  3. Pay the Last Mile Toll:  So you surrender your digits and wait for a phone call. When it rings 36-72 hours later, you’re determined to keep it short. What you want is a simple yes/no on service at your ROBO, or an install date, but what you get is a salesperson who can’t spell TCP/IP and wants to sell you substandard VoIP & TV. “Will you be uploading or downloading with this internet connection?” is just one of the questions you’ll suffer through to mollify the last mile gatekeepers standing between you and #PacketGlory on the WAN.
  4. At long last, install day arrives: You’ve drop-shipped the edge router/overlay device, you’ve coordinated with the L-con, and the CableCo tech is on site at your ROBO to install your circuit. Hallalelujah, you think, as you wait for the tunnel to come up. But it never does, because between your awesome zero-touch edge device & your datacenter lies some crazy bespoke 2Wire gateway device that NATs or offers up a free wifi connection to the public on your dime. Another phone call, another fight to get those things turned off.

Nuts to all that, I say.

This is America jack, and the great thing about America is choice. Even when you don’t have choice (and you don’t in the case of cable franchises & municipalities), all you may need is line of sight to one of these things:

Mmmm. Microwaves.
Mmmm. Microwaves.

That’s right. Fixed wireless, baby. I’m hot on fixed wireless in 2015. It’s everything CableCo isn’t. It’s:

  • Friction free: In place of the coax fiefdoms and gatekeepers, the 1-800 numbers, and the aggressive salespeople, there’s just Joe, a real engineer at a local fixed wireless ISP. Joe’s great because Joe’s local, and Joe takes your order, gives you his mobile, installs the antenna at your branch, and hands you a blue wire with three static IPs.
  • Super-fast to deploy. You want internet at your ROBO? Well guess what? It’s already there, you just need the equipment to catch it.
  • More reliable than it used to be: Now of course this all depends on the application you’re trying to deliver to your ROBO, but I’ll say this: Fixed Wireless has improved. You don’t need to fear (as much) a freak snowstorm, a confused flock of Canada Geese, or rain. For a small ROBO, a fixed wireless connection might be enough to serve as the primary WAN link. For larger ROBOs, I think the technology is mature enough to serve as a secondary WAN link, or even your primary Internet circuit. ((Routing business traffic over the expensive wired link and internet over the cheap fixed wireless link is a recipe I’d recommend all day long and twice on Sundays ))
  • As Secure as Anything Else These Days: How difficult would it be to perform a man in the middle attack via interception of a fixed wireless connection? I’m not sure, to be honest, but if you aren’t encrypting your data before it leaves your datacenter, you have a whole lot more to worry about than a blackhat with a laptop, a stick, and a microwave antenna.
  • Cost competitive: I’ve deployed a couple of fixed wireless connections and I find the cost to be very competitive with traditional cable company offerings. Typically you’ll pay about $200 for the antenna install, but unlike the fee Comcast would charge you to install their modem, I think this is justified as it involves real labor and a certain amount of risk.
  • Regional/Hyper-local but still innovative: For whatever reason, fixed wireless ISPs have proven resistant to the same market forces that killed off your local dial-up/DSL ISP. Yet this isn’t a stagnant industry; quite the opposite in fact, with players like Ubiquiti Networks releasing new products.

I’ve been working on the WAN a lot lately and I’ve deployed two fixed wireless circuits at ROBOs. If you’ve got similar ROBO WAN pains, you should have a look at fixed wireless, you might be surprised!