For the last couple of days I’ve been messing with Cisco’s VIRL on Packet’s bare metal service. I don’t do enough labbing now to spend multiple thousands of dollars building a lab in my house, and I want something that I can use from anywhere without opening a lot of holes in my home network when I’m on the road, so the Packet service seems like something useful to get running.
Forthwith, some observations and hints for those who might be thinking about doing this. Some of this might be obvious to other folks, I know, but—maybe me writing them down here will be somehow helpful, and save other folks some time.
An observation—this all feels a little (okay, maybe a lot) clunky’ish. There’s a lot of steps, it takes a long time to set up, etc. There are a lot of moving parts, and they interconnect in interesting ways. Maybe this will all get better over time, but for now, if you’re going to do this, plan on spending at least a half a day, probably more, just getting all the pieces to work.
Some places I ran into trouble, and things I needed to configure that I had to play with to discover.
If you have problems with connection timeouts from vagrant into the virtual box, make certain virtualization is turned on in your bios. Any time you change virtualization, etc., it’s best to destroy the virtualbox machine and let the vagrant script rebuild it. It took me two or three such rebuilds to get past the initial steps of getting ssh’d into the virtualbox machine.
You have to copy client.ovpn to your configurations directory in openvpn each time you run through the startup process, as the ip addresses change each time. I tried to use the Windows 10 native vpn client, but I can’t figure out how to transfer the information in the config file into the native client’s settings—this would be just one bit cleaner if I could figure that out. If I do, I’ll post something on it later. Beyond this, I tried to get openvpn to read the config file from the vagrant directory by changing some registry settings, but this doesn’t seem to work. I’ll work on this more later, as well, to see if I can figure out why, but for now, just put it in your steps that you need to copy this file over manually each time you run through the startup.
If you want to run Maestro (you probably do), the setup process isn’t very obvious.
You have to generate the VM Maestro application download before you can actually download it. All the stuff I could find on line said, “just go to the download sare, and you’ll see the download available.” Well, I didn’t. I had to go to the VIRL Software tab and generate the download—see the screen shots below to see what the process looks like.
When I first ran Maestro, I skipped past the initial configuration screen, so I had to dig though the settings to find where to put things. When I did set these up, it asked me for a username and password—nothing I put in here worked. The setup screen, however, has a space for a default username and password. Apparently, the little dialog box that pops up asking you for a username and password doesn’t do much of anything. I changed the default to the ones in my passwords.tf file, and now it works. Below are some screen shots of the setup as it works for me. You’ll want to create a new profile for the packet cloud—something I’ve not done yet.
Like I said, a lot of this might be obvious to other folks, but I found these bits puzzling. If anyone has questions about this process, or more thoughts, feel free to leave comments below.