8 - Building a DMZ for the ASAv and Enabling ICMP Inspection

This post will serve as a basic guide to creating a DMZ for a web server. Additionally, ICMP inspection will be enabled to allow the intern PC to ping outside. 

To begin, ASDM will be used to configure static NAT 192.168.14.55 (Faux Public IP Used for Lab) and associate it with web server (which will be built) IP 10.2.0.55. Port 80 will then be opened for web server traffic with the ACL on ASDM. Lastly, ICMP will be enabled for packet inspection - like some protocols this is disabled for packet inspect by default.

Like every other post, this post will serve as an expansion of previous; but can also serve as a standalone. For background, below is the summary of the current setup:

To recap, here is the summary of the lab configuration so far:

• 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.
• The virtual PC is configured with 8.8.8.8 DNS Server
• The ASAv is configured with dynamic PAT to allow internal IP address to translate to a public IP for communication
• SSH is configured for outside traffic to manage the router.

STEP 1 - Creating a Router as the Web Server

Router, Web_Server, will be created to sit at the DMZ. It's configurations will allow it to be an http server. Web_Server will communicate from it's IP of 10.2.0.55 and route to the ASAv to be configured DMZ IP 10.2.0.66.

The router node is first added, named, connected and started before configuration. As noted in Post 2, the VIRL based nodes don't exactly match up with the GNS3 interface names. In this case the Gi0/0 matches the CLI.

enable

configure terminal

hostname Web_Server

interface gig0/0

ip address 10.2.0.55 255.255.255.0

no shutdown

exit

ip route 0.0.0.0 0.0.0.0 10.2.0.66

ip http server 

ip http authentication local

username admin privilege 15 secret toor

end 

write

As an added touch, right click Web_Server and select 'change symbol.' Search 'server' and click okay.

Step 2 - Using ASDM to configure the ASAv DMZ

Post 2 shows the configuration of the ASAv using the command line. Alternatively, this post will show the ASAv configuration using the Application Specific Device Manager. To get the planned setup interface gig0/2 going out will be configured with the 10.2.0.66 IP, and security level 50. After which NAT will associate public IP 192.168.14.55 with the Web_Server. The Access Control List will then allow for the outside world to reach Web_Server.

Navigate to Configuration to Device Setup to Interface Settings to Interfaces. Double click GigabitEthernet0/2 to edit.

Edit Interface will open. Change the following settings:

Interface Name: DMZ

Security Level: 50

Enable Interface: Check

IP Address: 10.2.0.66

Subnet Mask: 255.255.255.0

Click OK twice and Apply

To check connection to Web_Server, navigate to Tools to Ping. Fill out ip 10.2.0.55 and click ping. The output should show success.

Now to the NAT configuration!

Navigate to Configuration to Firewall to Objects to Network/Objects/Groups. From the Add drop down, select Add Network Object. Fill out the information as shown:

Name: Web_Server

IP Address: 10.2.0.55

Click OK and Apply

Add another NAT object for Web_Global.

Name: Web_Global

Type: Network

IP Address: 192.168.14.55

Netmask: 255.255.255.255

Click OK and Apply

Navigate to Firewall to NAT Rules. Add 'Add NAT Rule Before "Network Object" NAT Rules..."

Fill out the NAT Rule with below:

Under Match Criteria: Original Packet

Source Interface: outside

Destination Interface: DMZ

Destination Address: Web_Global

Under Action: Translated Packet

Destination Address: Web_Server

Click OK, Yes, Apply, and Save

Navigate to Firewall to Access Rules. Add Access Rule. Fill out as shown:

Interface: outside

Destination: Web_Server

Service: tcp/http

Click OK and Apply and Save

Step 3 - Accessing Web_Server from the Outside Interface

This step mimics connection to the Web_Server behind the DMZ from the WAN.

Navigate to a browser and type the IP for Web_Global. Login with user name and password, admin and toor respectively.

Success! The server is now accessed through the WAN.

Step 4 - Enabling ICMP Inspection

As an added bonus, the virtual PC will be configured to ping into the internet. By default, ICMP replies are not inspected. 

Navigate to Configuration to Firewall to Service Policy Rules. Select inspection_default and click edit.

Go to the tab Rule Actions, Protocol Inspection and check ICMP.

Click OK, Apply and Save.

From the virtual PC, ping google.com.

ping google.com

Success!

7 - Enabling Router SSH through ASAv ASDM over the WAN

Enabling Router SSH through ASAv ASDM over the WAN

This lab will allow remote administration for the router, R1. Static NAT to translate a one to one ASAv association addressing for the router and enabling SSH will be the primary methods of accomplishing this. 

To recap, here is the summary of the lab configuration so far:

• 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.
• The virtual PC is configured with 8.8.8.8 DNS Server
• The ASAv is configured with dynamic PAT to allow internal IP address to translate to a public IP for communication

STEP 1 - Enable Static NAT

Static NAT allows internal addressing to be assigned a public IP address. This allows for external users to a way to map and access internal services. The ASAv is the gateway for the internal and external network which the router belongs to. Thus the ASAv will be logically configured for Static NAT to match a public IP address to the internal IP of the router.

Enabling Static NAT begins with creating two network objects.

The first is R1. Navigate to Configuration to Firewall to Objects and Network Objects/Group. Then from the Add drop down select Add Network Object. Fill the object out as presented below:

Name: R1

Type: Host

IP Version: IPv4

IP Address: 10.1.0.1

Description: Router

Click OK.

The second object to be added will be Global-R1:

Name: Global-R1

Type: Host

IP Version: IPv4

IP Address: 192.168.14.131

Description: Public IP

Click OK.

STEP 2 - Configuring NAT Rule

The NAT Rule will allow the traffic to know how to get to a destination. It converts a known IP to the hidden IP. In this case we'll configure the Global IP address (192.168.14.131 I know this is a private IP for our scenario, but in production this would be Global) to associate with the internal router IP address (10.1.0.1).

To configure NAT Rules, navigate to Configuration to Firewall to NAT Rules. Then from the Add drop down select, Add NAT Rule.

We'll configure it as below:

Source Interface: outside

Destination Interface: inside

Source Address: any

Destination Address: Global-R1 (You need to click the 3 dots and select the object Global-R1 which was previously created)

Service: Any

Source NAT Type:Static

Source Address: Original

Destination Address: R1 (You need to click the 3 dots and select the object R1 which was previously created)

Enable Rule is checked

Click OK

Step 3 - Permitting the ACL for SSH traffic

While the NAT shows the traffic what path to take, the ACL gives permission on if the traffic is allowed to take the path. We'll allow the ACL to permit traffic to manage the router via SSH.

From Configuration to Firewall to Access Rule, select the Add Access Rule from the Add drop down.

Fill out the form as shown below:

Interface: outside

Action: Permit

Source: any

Destination: R1

Service: tcp/ssh

Click OK

Step 4 - Applying and Saving ASDM Configuration

Once we've configured ASDM as shown above, we'll go ahead and Apply and Save as shown in the screen shot.

Step 5 - Configuring Router for SSH

The ASAv is now configured to where NAT rules can provide location, and the ACL can permit SSH traffic to pass. Although if a user tried to SSH now, they would still not be able to since the router isn't configured for it. Our next step will allow for this.

From the router:

configure terminal

hostname R1

ip domain-name ecorp.com

crypto key generate rsa modulus 1024

username admin privilege 15 secret toor

line vty 0 4

login local

transport input telnet ssh

end

write

Step 6 - Testing SSH Connection through the WAN

Putty or any SSH terminal can be used for this next step. If you don't have Putty installed go ahead and do so now. It's a self explanatory and simple process. Once Putty is up, configure the Host Name with 192.168.14.131 and click okay. Make sure you're on a personal network. You don't want to be on someone else's network where you can access a machine of the same IP address.

A Security Alert Pops up for me. I clicked okay, you should be fine if you're on a personal network.

The command line will request credentials. Place admin and toor as the username and password respectively - and viola!

From the router, you can also see that there's an external connection.

show ssh

who

ASDM will also show the SSH connection.

Navigate to Monitoring to Properties to Connections.

6 - Proving Why Trace Fails Using Wireshark

Proving Why Trace Fails Using Wireshark

Intro

With the current lab setup (review below), trace from the virtual PC to the internet will not. The ASAv works with stateful packet inspection by default to only allow incoming external traffic if it was first requested from an internal source. Lower security levels (Outside Interface Security-Level 0) will allow incoming traffic if the higher security level (Inside Interface Security-Level 100) has first requested for it. A trace from the virtual PC to the WAN, looks like this is the case. But, a deeper look of analyzing the traffic's protocol, ASAv denies the return traffic because it is unrecognizable - to the ASAv, it doesn't look like the traffic was internally requested.

Before continuing the proof, below is a summary of the current state of the lab environment:

• 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.
• The virtual PC is configured with 8.8.8.8 DNS Server
• The ASAv is configured with dynamic PAT to allow internal IP address to translate to a public IP for communication

STEP 1

Wireshark integrates with GNS3. It can be downloaded separately, if your initial GNS3 setup didn't. This tool will allow us to capture traffic to see what's going on with the trace failing from the virtual PC to the outside world.

Write click the line outside of the ASAv and click start capture.

A pop up will show that allows you to name your packet capture. I've named mine Proving Failed Traces.

Once you've named the file, Wireshark will open up and start capturing traffic.

STEP 2

Let's place some traffic to analyze with Wireshark by forcing the fail from PC1.

trace google.com

As you can see, the fail shows when tracing google.com

STEP 3

Let's analyze the traffic back in Wireshark. 

As seen, the traffic starts with querying the 8.8.8.8 DNS Server to resolve Google's IP address. Once we have that the trace begins with the PAT'd address of the virtual PC, which is the ASAv's outside interface (faux public IP 192.168.14.130). The protocol going out from the PC out to Google is UDP. When traffic returns from the router (faux public IP 192.168.14.2) the incoming protocol is ICMP. Because ASAv uses stateful packet inspection, ICMP is unrecognized since it was not a protocol initiated from a higher level security (or the internal network).

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.