I had a very interesting experience today with my Check ASA 5506X. I have been working on migrating about 15 virtual severs I run to a new sever VLAN to include my Graylog logging sever which actively collected all my syslogs across the network. I had chosen a new IP address and updated the server with new IP address. Soon after doing so I noticed that I had lost Internet connectivity.
I had checked DNS and my routing and everything checked out. After some hair-pulling I jumped into my ASA and began poking around. I knew I hadn’t changed anything on the fw but decided to run a packet-tracer check to see what the results of a normal flow out of my ASA into the Internet would result in. It failed. Correlating my recent activities to my current issue the only common denominator was the syslog server in which my ASA was configured to use. I decided to remove the logging configuration and low and behold my Internet returned. I consulted Cisco’s latest guidance and found that this is expected behavior be default if a connection to a logging source becomes broken.
The recommended approach going forward would be to remove the logging config before change IP addresses on yoru log server OR to add the configuration the would prevent this action on the ASA. This is a natural security concern as any malicious intruder would look to erase any tracks of his/her misgivings and in doing so would kill their intrusion into your organizations fw. I opted to disable this security mechanism and contend with the fail-open regarding logging.
Cisco ASA 5506X running 9.8(1)
(config)# logging permit-hostdown
If your running Graylog and looking to update it’s IP address you need to modify the server.conf file located in /etc/graylog/server/. Update the rest_listen_uri and web_listen_uri sections of the config and restart graylog service
Updating the IP address to your Graylog server requires taking a few additional steps beyond modifying the server’s IP.
Ubuntu Server 16.04 LTS running Graylog v2.3
sudo nano /etc/graylog/server/server.conf
Edit the following sections within the server.conf file:
rest_listen_uri = <new_ip> web_listen_uri = <new_ip>
Lastly you need to update your inputs and change the binding address to reflect the new IP:
Lets just get right down to it, your success in technology studies comes down to a few key things, not least of which is the self-training environment you build to run the simulations, emulations, or virtualized networks you need to run to get some hands-on. I wanted to share with you the training lab environment I’ve conjured up to meet my needs for certification and theory crafting, a Frankenstein concoction of the best virtualization technologies to-date, deployed in a fashion that complement each other nicely. Before I go into the lab design and setup I’ll take a few moments to cover my past lab environments and share my opinions on what I liked and didn’t like before ultimately settling on the architecture I run today.
I had originally ran a typical GNS3 lab in which I supplied my own IOS images. This ran fine but I was limited to the IOS I could run within GNS3 (mostly IOS v12 with exception to the 7200 series router). At this time the GNS3 VM did not exist and so growing my labs to scale became an issue as well. Furthermore the switching scene was almost non-existent. This lab ran on my custom built desktop PC in which I had to power the whole thing down and re-tweak when I powered my PC back on.
Flash forward to recent times and GNS3 has gone through a lot of changes. We now have the latest GNS3 v1.x software code which brings a lot of things to the table. We have the GNS3 VM which is an appliance vm that does a lot of heavy lifting running networking nodes on behalf of the GNS3 application/server itself. Additionally there is better support for VirtualBox and VMware technologies so that we can better inject our virtual systems into our GNS3 topologies.
Cisco has been working on their own lab virtualization platform referred to as VIRL. VIRL does, for the most part, exactly what GNS3 does. It allows us to run virtual Cisco nodes (firewalls, switches, and routers, etc) inside of a framework that allows us to build real-world topologies to test and practice on. I had paid and used VIRL for a short stint before scrapping and coming back to GNS3. VIRL was a great tool but it was slow and somewhat bloated for my personal needs. VIRL also has some stringent hardware needs before you can really take advantage of its power, a deal-breaker for some.
All of these trial and tribulations have lead me down the road I’ve been on to liberating my virtual lab in such a way as to provide a robust and stable platform offering, in my humble opinion, the best-of-breed technologies.
Physical Server – I highly encourage you to procure a purpose built server with the following minimums. I run a DELL T610 tower server which exceeds the below specs. eBay has some pretty good prices.
- CPU – (2) Intel quad-core Xeon
- Memory – >30GB
- Disk – 500GB of storage space (ideally a RAID 10, 15K rpm SAS 6G volume )
- NIC – (2) 1Gbps Ethernet
- [free] VMware ESXi – This will be installed on our bare hardware, providing the foundation of our lab environment.
- [$] VMware Workstation Pro – This will run the desktop and server elements of our GNS3 labs.
- [$] Cisco VIRL – Obtaining a software license will provide access to downloading the official Cisco router, switch, and firewall images we will run in GNS3 (not VIRL)
- [free] GNS3 – GNS3 is the hosting application that will pull the VMware workstation servers and desktops and teh GNS3 VM ran Cisco VIRL nodes into the same lab topology. Its kinda of a big deal.
- [free] GNS3 VM for VMware ESXi – This will run the Cisco VIRL nodes we will download.
- [$] Microsoft Windows Server – Run Windows Server in eval mode (180 days) or obtain a single license. This will host the GNS3 and VMware Workstation software elements of our lab.
The design and architecture that I have settled on consists of a dedicated, physical, purpose-built server that runs VMware ESXi. This gives us flexibility and freedom to rework and tweak our lab needs over time as things change. The snapshot and virtual networking capabilities we gain from a virtualized environment are a necessity for building a sound lab environment foundation that can meet today’s ever-changing techno landscape. Moving past the hyper-visor layer, we will run two virtual machines, a Windows Server vm and a GNS3 VM appliance. The GNS3 VM appliance (not to be confused with the GNS3 server software we will additionally run) is a self-contained Linux based server that will efficiently run our Cisco VIRL node images. We will configure the GNS3 server software to connect to this vm so that we can add Cisco routers, switches, and firewalls to our labs.
The Windows Server vm will run the VMware Workstation and GNS3 server software. A key reason for choosing to run Windows Server (i’m a fanboy of all things Linux) is its robust RDP protocol. When all said and done (and assuming your personal computer is Windows based) we will access our lab environment over RDP by running a remote desktop connection to this Windows Server virtual machine. After much experimentation with a few different remote connection protocols, nothing came close to the experience that RDP provides. We also need our lab hosting machine to run continuously with no ill side-affects, so any Desktop flavor of Windows is out of the equation as it just isn’t meant to run services 24/7 (memory consumption, power saver, etc). VMware Workstation came into the picture as I began looking for the best host-based virtualization solution for adding virtual computers and servers into my GNS3 labs. I initially ran VirtualBox which worked pretty well for most of my needs. I only began moving away from VirtualBox as I needed better support for the Cisco appliance servers I wanted to run (Cisco ACS, ISE, UCM, etc) which natively supported VMware ESXi. The VMware Workstation GUI also unified all the virtual server and desktop screens under one umbrella as opposed to a bunch of independent application windows spread out across my monitor as was the case for VirtualBox. The GNS3 server software, our last element for discussion, provides the lab environment itself. Its within the GNS3 server lab that we will import our VMware Workstation ran servers and desktops and our GNS3 VM ran Cisco switches, routers, and firewalls, unifying our lab environment.
VMware ESXi – I always recommend installing ESXi to an internal SD flash card or internal USB flash drive as opposed to the internal disk based storage of your server. ESXi is a small OS that runs in memory, once booted, and installing to removable media gives us the flexibility to upgrade and migrate as needed in the future without much pain. Your disk based storage should be dedicated to hosting the virtual datastore that we will be storing our virtual machines on. Download VMware ESXi, burn to disc, and boot to it. After installing ESXi, reboot and log into your ESXi web interface. Setup the ESXi datastore and import the GNS3 VM appliance.
GNS3 VM – The GNS3 VM appliance is an OVA file we downloaded from the GNS3 website. After importing the GNS3 VM we can boot it up and configure its IP address. We can do this through the virtual machine console. Ping the GNS3 VM from your computer to make sure it has network connectivity. After the GNS3 VM we need to get our virtual Windows Server up and running.
Windows Server – I choose to run Windows Server 2012 Standard edition for my needs. Provision your Windows Server vm with enough resources to run the VMware Workstation and GNS3 server software it will be hosting for us. I choose to assign 16GB of memory on a 200GB vDisk. I also recommend assigning 8 vCPUs (2 sockets) and paying special attention to tick the checkbox within vm settings to “Expose hardware assisted virtualization to the guest OS”. This helps when it comes to running VMware Workstation within our vm (virtualization within virtualization). After getting Windows installed, configure the IP address and install and needed Windows updates. Enable RDP access to your system and test remote desktop connectivity to your Windows Server vm. Once everything is Kosher, download and install the VMware Workstation and GNS3 server software.
VMware Workstation – I’m using Workstation Pro 14. To be continued…
For those of you that may not know (and most don’t), there is an excellent freely licensed (for home use) shell, ssh, telnet and serial terminal emulator for the Windows platform that I have been using (when not using my tried and true Secure CRT) for some time now call Xshell 5 by NetSarang. Xshell 5 is a fantastic piece of software that has some really cool features baked in that I truly enjoy. My most favorite feature is the tabbing feature called “Arrange Tiled”. This golden nugget feature allows me to easily fill up my screen real-estate with vty session windows (or whatever session you tend to use). Marry this emulator with GNS3 and you have a command line experience that’s hard to get elsewhere.
To get Xshell 5 to work in GNS3 simply navigate to Edit > Preferences. Under the General section click on the Console Applications tab on your right. Click on the ‘Edit’ button next to ‘Console application command for Telnet:’ and from the resulting menu that emerges simply use the drop-down menu to select Xshell 5 as GNS3 has built-in support for this. Now you can finally feel like a true Hollywood nerd. Happy hacking.