4 - Bootstrapping Router Configuration

I'm trying to make my posts a standalone where it covers a topic that doesn't have to reference my previous posts. Although they will still build on the previous posts. Configuring a router is a little difficult because it all depends on the environment you build it in. 

The context of this router requires that the virtual PC be able to route to the appropriate destination. In this case, the router's next hop it's responsible for is the ASAv.

Let's get started. 

Similar to my ASAv, my router image was built from the VIRL IOSv. This is what I'll be using in the topology. Once you build the topology as shown below, go ahead and turn all devices on.

Now let's configure the router to pass traffic. This is done by assigning the interfaces an appropriate IP address, and enabling the interface. Then we'll set the IP route, so it'll know what to do with the traffic sent to it. We'll issue a ping to make sure it succesfully talks to the ASAv Gig0/1 interface. If successful, lastly save the configuration.

conf t

int gig0/2

ip address 10.0.0.1 255.255.255.0

no shutdown

exit

int gig0/1

ip address 10.1.0.1 255.255.255.0

no shutdown

exit

ip route 0.0.0.0 0.0.0.0 10.1.0.250

end

ping 10.1.0.250

write

That's the basic setup for the router. Now we'll work with providing the IP address to the virtual PC.

ip 10.0.0.25 255.255.255.0 10.0.0.1

show ip

ping 10.1.0.250

save

The ping works from the PC to the ASAv inside interface. So that means our router is working just fine!

3 - Enabling ASDM in GNS3

I've looked up a few how to articles online on how to bring up the Adaptive Security Device Management (ASDM) from a virtual environment. They all seemed either too complicated, or used a very different interface for GNS3. After a lot of trial and error, I found the simplest way to bring up the ASDM in a virtual lab environment.

To recap post 2, the ASAv has a successful bridge with the host laptop to allow a connection out to the internet. VMNet8 is configured to allow my host laptop to fit in the IP addressing. This will later allow, my web browser to access the ASAv. But first we have to make some configurations to allow http traffic range going to the ASAv. We'll also change the hostname in the process. Then we'll save.

http server enable

http 192.168.14.0 255.255.255.0 outside 

hostname asa-1

write

Once we've enabled an http connection, we can connect to the ASAv through a browser. Note, the IP address 192.168.14.130, is the assigned IP of the outside interface.

Type this into the browser: https://192.168.14.130

Click "Proceed to 192.168.14.130 (unsafe)" 

Proceed with the installation of the ASDM or Java Web Start install. Either way will allow the use of ASDM. The instructions that follow are pretty self explanatory. If any authentication requirements show, go ahead and click login. By default, there is no user name or password required.

Once the installation of the ASDM is finished, find the ASDM launcher and open it. I had to open Windows Start and search for ASDM to open the launcher. There will be a prompt requesting the Device IP Address / Name, make sure you have the outside interface's IP address listed as 192.168.14.130. Again, Username and Password will not be required. Click okay.

You will receive prompts, go ahead and confirm them. Finally you should have access to the ASDM. You can configure the ASAv through this graphical user face. I'll show some examples a few posts down. But first the rest of the lab environment must be created.

2 - Allowing Internet Relationship for ASAv to WAN in GNS3

My lab begins with making sure the network setup is correct. This will allow the ASAv in the GNS3 lab environment to communicate with other devices as well as out to the WAN. I'm using vmnet8 in my lab with the following configurations:

• Subnet IP: 192.168.14.0
• Subnet mask: 255.255.255.0
• Gateway IP: 192.168.14.2

In the design below you will see 3 switches, 1 ASAv and 1 cloud topology. The setup expands as my posts on the ASAv progresses. But for now our main focus is the ASAv and Cloud1.

Once the devices have been placed onto the topology, Cloud1 can be configured by right clicking and select properties. Under the Ethernet interfaces tab, enable "Show special Ethernet interfaces" This allows VMWare Network Adapter VMnet8 to be selected from the drop down and added to the list below. Delete all other interfaces so only VMWare Network Adapter VMNet8 is in the configuration for Ethernet interfaces as shown:

The ASAv is next to be configured. We will need to specify that the ASAv will be connected with multiple devices. So, under the network tab, adapters is configured to 4.

I've found out that the naming convention for my nodes do not match between what GNS3 shows and my command line. I troubleshooted this out by guess and check to see how the routes communicated. This seems like a common problem with other people labbing with VIRL images on GNS3. The node names on GNS3 just need to be changed so there won't be any confusion on what interface you're actually configuring.

(Above are the default GNS3 node names)

(Above are the new node names that match my CLI)

Now it's time to power on the ASAv and configure terminal. You do this by right clicking the ASAv for power on and opening the command line. Also, when going to enable/privilege mode, there are no passwords upon initial boot, so just press enter.

enable

conf t

From here we'll switch to interface modes to provide security levels, interface names, ip, and enabling.

ASAs have stateful inspection by default. This means that traffic from interfaces of lower security levels can't go through interfaces of higher security levels, unless they where first requested from higher security levels. In this case the outside interface which points to the internet, by default, can only enter the inside interface, where the LAN resides, if traffic was first requested by the LAN to the internet. The magic happens by giving the outside interface, security-level 0, and the inside interface, security-level 100.

int gig 0/0

security-level 0

nameif outside

ip address 192.168.14.130 255.255.255.0

no shutdown

exit

int gig 0/1

security-level 100

nameif inside

ip address 10.1.0.250 255.255.255.0

no shutdown

exit

Now we'll configure routing for named interfaces. As noted earlier, we have gateway 192.168.14.2 to the outside interface. This is a private IP in a lab, but should be public in reality. If the configurations where made correctly, the route should allow ASAv to successfully reach the internet. My ping proves that mine does - the ASAv successfully communicates to the outside world (WAN) from a GNS3 simulation.

route outside 0.0.0.0 0.0.0.0 192.168.14.2

route inside 10.0.0.0 255.0.0.0 10.1.0.1

ping 8.8.8.8

Finally, don't forget the write command to save the configuration. We'll use this lab again to build out the rest of ASAv as we expand the environment.

write

1 - Introducing ASAv Labs

Lately I've been brushing up on my CCNA Security skills. Turns out, there has been a lot I'd forgotten since I've taken the test. It's been fun learning about it again - especially since I've figured out how to use GNS3 to build a lab environment. It's a whole lot better to understand concepts when you have a hands-on approach after learning about it. The labbing really helps bring concept vagueness into clarity. In hopes to remember my CCNA Security, I decided to start noting and posting about my lab process.

The next few posts will be about the labs I have been working on. I'll be using VMWare Workstation 12 Pro for my GNS3 VM, and version 2.0.3 of GNS3, and an ASAv 9.4(1) image exported from VIRL. The benefit is for me, but maybe it may help any readers out there with a similar setup. 

Cost Savings and Policy Compliance with Encryption Management Solutions

Encryption solutions can hit two birds with one stone by providing cost savings for the enterprise and becoming policy compliant.

All enterprises have a refresh period where older machines must be disposed and replaced with new ones. Tracking, these machines from user location to disposal, is a security measure to assure data inside computers don’t fall into the wrong hands. RFID tags/readers, personnel training, media sanitization, etc is a high cost for security through tracking. Alternatively, to mitigate security risks, encryption can be implemented. Once computers fit the expiration category, a managed encryption solution can allow a remote wipe of these computers – rendering the machines’ data virtually useless.

Both tracking and encryption will require media sanitization. With encryption management, media sanitization does not have to be another incurred cost. Encryption management solutions can provide this process already. As an additional bonus this is compliant with federal standards including.

Moving beyond cost saving benefits, encryption solutions can also provide policy compliance with the specific enterprise. In theory, enterprises have manuals that provide a high level view of security compliance requirements. Encryption management solutions can be provisioned to meet the data at rest requirements.

The two benefits of cost savings and policy compliance are met with encryption management solutions.