5 - Configuring Dynamic PAT using ASDM

In this post I'll build dynamic PAT for the ASAv Firewall through ASDM. 

Dynamic PAT allows masking of the internal IP addresses to the outside world. In live scenarios, a firewall would have a public IP on the outside port. With this lab we'll pretend our private IP 192.168.14.130 is that for us. As an overview, here's how the lab is built:

• Cloud1 represents the WAN.
• ASAv has an outside interface of 192.168.14.130 (pretending this is our public IP)
• ASAv has an inside interface of 10.1.0.250
• ASDM is successfully built with reachability using the outside interface 192.168.14.130
• The network behind the ASAv is designed with 10.0.0.0/24 
• The router is configured to route traffic with a default gateway to the ASAv
• The virtual PC is configured with the router as the default gateway
• The virtual PC can successfully the ASAv's inside IP 10.1.0.250.

To get started open the ASDM and navigate to NAT Rules. So that's Configuration to Firewall to NAT Rules. Then click the Add drop down and select Add "Network Object" NAT Rule...

A screen displays that allows configuration of the Network Object. I leave everything as default, with the exception of the description below:

Name: Sub10

Type: Network 

IP Address: 10.0.0.0 

Netmask: 255.255.255.0

Under NAT --> Type: Dynamic PAT

Under NAT--> Translated Addr: (Select the 3 dots, which brings up the interfaces. Select outside interface and click ok)

Once that's all filled out, I click OK.

I click Apply and Save to bring it live and save it onto the ASAv.

I'll open the ASAv command line and verify the rule has been applied.

enable

show nat

Now I'll test that the rule works.

I expect that the NAT rule configured, will translate source address of 10.0.0.0/24 to outside destination addresses.

I'll set the virtual PC with an external dns server. This allows me to utilize a domain name instead of using the IP address alone, as the DNS server translates the IP to a domain name for me. Then with a trace to Google command, the NAT rule should automatically apply.

ip dns 8.8.8.8

trace www.google.com

CTRL C to stop trace

save

I stopped the trace because the ASAv will drop the packets coming back in. By default ASAv will not allow the ICMP return packet, since the request out used the UDP protocol. I just wanted to make sure that the DNS would translate, and to see NAT in action.

To prove the NAT worked, I go to the ASAv CLI

show xlate

The xlate shows the translation in the translation table. It shows the 10.0.0.25/24992 being assigned a port and translated as the outside address using the same port 192.168.14.130/24992.

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.

God Mode Driver

Responsibility grows hand in hand with trust. In technical operations, the metrics of responsibility are access rights. The metrics of trust will be the same universally; information security does have a greater emphasis on information confidentiality, integrity and availability. When trust reaches an apex, technical operators are given the responsibility of superuser. It is an account that is not limited to trivial tasks of system maintenance. It is a responsibility of omnipotent access. This is the superuser mode aka God mode. 

 

Experience in changing car oil, jump starting a vehicle and changing a flat tire would be top priorities for first time drivers. Before the privilege of adventurous road trips, drivers should know these basic principles. Privilege is granted to the amount of responsibility handled. Else, detrimental consequences.

Technical operators abide by this principle as well. They remain Tier One until they show effort towards responsible. In time, privilege can be granted. Their marks will be in trustworthiness and competence. As adventurous road trips mark the apex of faithful driver, so the superuser privilege to a faithful technical operator.

The apex is not the end of the adventure. There is a place for maintenance. Oil needs to be changed or a car break. The superuser needs to continue growing in their responsibilities and trust or rights may be revoked. Achievements are good only for only as long as it lasts. Trust and responsibility is an ever growing characteristic in daily life but also in data confidentiality, integrity and availability.