In ASDM, select Configuration > Firewall > NAT Rules There should be one entry in the NAT Rules table associated with the nat 0 command:

5.2. At the bottom of the table, Enable Traffic thru the firewall without translations should be checked, associated with the no nat-control configuration.

6. Explore the behavior of connections from the Admin PC on the inside interface to the PERIM router on the outside interface:

6.1. Establish an SSH connection from the Admin PC to the Perimeter Router: 6.1.1. On the Admin PC, launch another instance of PuTTY.

6.1.2. This time double click on the PERIM saved session. 6.1.3. Authenticate with the credentials admin and admin$Pwd.

6.1.4. Use the show users command to verify that the connection is coming from the Admin PC’s untranslated 10.10.10.10 address:

PERIM#show users

Line User Host(s) Idle Location 0 con 0 admin idle 00:13:23

*514 vty 0 admin idle 00:00:00 10.10.10.10 Interface User Mode Idle Peer Address

6.2. Establish another connection to the Perimeter Router from the Admin PC, this time via Telnet:

6.2.1. On the Admin PC, launch a Command Prompt window:

6.2.2. In the command prompt window issue the command telnet 200.200.1.1, and authenticate as admin with the password admin$Pwd.

6.2.3. Again, use the show users command. Now there should be 2 sessions from 10.10.10.10:

PERIM#sh users

Line User Host(s) Idle Location 0 con 0 admin idle 00:00:45

514 vty 0 admin idle 00:00:27 10.10.10.10 *515 vty 1 admin idle 00:00:00 10.10.10.10 Interface User Mode Idle Peer Address

6.3. Examine the ASA’s translation table via the CLI:

6.3.1. Use the show xlate command in the PuTTY connection to the ASA:

GKL-ASA(config)# sh xlate

2 in use, 2 most used

Global 10.10.10.10 Local 10.10.10.10 Global 10.10.1.10 Local 10.10.1.10

Note You should definitely see the Admin PC’s local address 10.10.10.10 translated to itself. You may see other entries in the translation table due to (currently

unsuccessful) outbound traffic attempts for DNS or NTP.

6.3.2. Try again, this time adding the detail argument to the show xlate command:

GKL-ASA(config)# show xlate detail

2 in use, 2 most used

Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random, r - portmap, s - static

NAT from inside:10.10.10.10 to outside:10.10.10.10 flags iI NAT from inside:10.10.1.10 to outside:10.10.1.10 flags iI

Note Adding the detail argument changes the format of the output slightly and includes flags. The Admin PC’s translation entry is both dynamic (i) and Identity I. Identity NAT is the name of the feature implemented with nat 0.

6.4. Examine the ASA’s connection table via the CLI:

6.4.1. Use the show conn command to view the ASA’s connection table.

GKL-ASA(config)# show conn

5 in use, 6 most used

TCP out 200.200.1.1:23 in 10.10.10.10:5296 idle 0:00:09 bytes 453 flags UIO TCP out 200.200.1.1:22 in 10.10.10.10:5292 idle 0:00:21 bytes 3380 flags UIO

Note There should be at least 2 connections in the table. Both originate from high numbered ports on 10.10.10.10. Both are to 200.200.1.1, but one is destination port 22 (SSH) and the other is destination port 23 (telnet)

Note You may find that there are more connections when you issue the command. Again, these are most likely from outbound NTP or DNS attempts.

Note Show conn displays the number of bytes transmitted in the connection. More bytes have been transferred in the SSH connection than the telnet connection. This is due to the relatively more complex connection negotiation for SSH which includes negotiating encryption protocols, passing of the server’s public key to the client and passing of the encrypted session key from the client to the server.

Note Show conn also displays flags. As with show xlate, including using the detail argument will display the meaning of the flags.

L3-7 © Global Knowledge Training LLC

6.4.2. As you did with show xlate, try the show conn command again, with the detail argument added.

GKL-ASA(config)# show conn detail

5 in use, 6 most used

Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN, B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN, G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data, i - incomplete, J - GTP, j - GTP data, K - GTP t3-response k - Skinny media, M - SMTP data, m - SIP media, n - GUP

O - outbound data, P - inside back connection, q - SQL*Net data, R - outside acknowledged FIN,

R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN, s - awaiting outside SYN, T - SIP, t - SIP transient, U - up, W - WAAS,

X - inspected by service module

TCP outside:200.200.1.1/23 inside:10.10.10.10/5296 flags UIO TCP outside:200.200.1.1/22 inside:10.10.10.10/5292 flags UIO

Note Now you can see the meaning of the flags. U indicates that the TCP connection is up (that is the 3-way handshake has completed. I indicates that data has been sent in the inbound direction. O indicates that data has been sent in the outbound direction.

Note The count displayed (5 in use in the example above) doesn’t seem to correlate with the output (which only shows 2 connections). By default, show conn doesn’t display the connections to and from the ASA itself. To include the connections to and from the ASA, use show conn all.

6.4.3. Use one more very useful command. Show local host combines aspects of both show xlate and show conn. Use the show local host command, specifying the IP address 10.10.10.10:

GKL-ASA(config)# sh local-host 10.10.10.10

Interface dmz: 1 active, 1 maximum active, 0 denied Interface inside: 2 active, 2 maximum active, 0 denied local host: <10.10.10.10>,

TCP flow count/limit = 5/unlimited TCP embryonic count to host = 0 TCP intercept watermark = unlimited UDP flow count/limit = 0/unlimited Xlate:

Global 10.10.10.10 Local 10.10.10.10 Conn:

TCP out 200.200.1.1:23 in 10.10.10.10:5961 idle 0:00:29 bytes 433 flags UIO TCP out 200.200.1.1:22 in 10.10.10.10:5824 idle 0:00:56 bytes 2912 flags UIO Interface outside: 2 active, 3 maximum active, 0 denied

7. Explore the behavior of connections from the DMZ Server on the dmz interface to the PERIM router on the outside interface:

7.1.1. Access the desktop of the DMZ Server.

7.1.2. Launch a Windows Command Prompt window.

7.1.3. In the command prompt window issue the command telnet 200.200.1.1, and authenticate as admin with the password admin$Pwd.

7.1.4. Again, use the show users command. Now there should be three sessions. Two from 10.10.10.10, and one from 172.16.1.15:

PERIM#sh users

Line User Host(s) Idle Location 0 con 0 admin idle 00:16:57

514 vty 0 admin idle 00:16:33 10.10.10.10 515 vty 1 admin idle 00:16:21 10.10.10.10 *516 vty 2 admin idle 00:00:00 172.16.1.15 Interface User Mode Idle Peer Address

7.2. Examine the translation table on the ASA via the CLI.

7.2.1. Return to the Admin PC desktop and access the SSH connection to the ASA. 7.2.2. Use the show xlate command in the SSH connection to the ASA:

GKL-ASA(config)# sh xlate

Global 10.10.10.10 Local 10.10.10.10 Global 10.10.1.10 Local 10.10.1.10

Note There are translations from the inside 10.10.0.0 network space, but there is not a translation for 172.16.1.15.

Note The reason the inside addresses appear in the translation table is due to the nat (inside) 0 0.0.0.0 0.0.0.0 command in the ASA’s configuration. There is no corresponding command associated with the dmz interface.

Note The reason the DMZ Server has outbound access, without translation, is due to the no nat-control command in the ASA’s configuration. But this does not cause dynamic entries to be placed in the translation table.

7.3. Examine the connection table on the ASA via the CLI.

7.3.1. Enter the show conn command in the SSH connection to the ASA:

GKL-ASA(config)# show conn

8 in use, 8 most used

TCP out 200.200.1.1:23 in 172.16.1.15:1106 idle 0:00:41 bytes 1097 flags UIO TCP out 200.200.1.1:23 in 10.10.10.10:5296 idle 0:00:13 bytes 453 flags UIO TCP out 200.200.1.1:22 in 10.10.10.10:5292 idle 0:00:25 bytes 3380 flags UIO UDP out 50.50.50.50:53 in 10.10.1.10:1035 idle 0:01:53 flags -

Note There should be at least 3 connections in the connection table: two telnet and one SSH connection to the Perimeter Router.

L3-9

© Global Knowledge Training LLC

Note The connection from the DMZ Server is in the state table. Turning off nat-control does not turn off stateful inspection.

8. Terminate the Telnet connections and verify the results: 8.1. First, terminate the connection from the DMZ Server:

8.1.1. Access the desktop of the DMZ server and close the Command Prompt window running the Telnet connection.

8.1.2. Quickly return to the Admin PC and the SSH connection to the ASA. Enter the show conn command:

GKL-ASA(config)# sh conn

5 in use, 8 most used

TCP out 200.200.1.1:23 in 10.10.10.10:5296 idle 0:00:32 bytes 453 flags UIO TCP out 200.200.1.1:22 in 10.10.10.10:5292 idle 0:00:44 bytes 3380 flags UIO

Note The connection from the DMZ Server to the Perimeter Router has already been removed from the state table. As soon as the ASA witnesses the TCP FIN exchange, it knows the connection has terminated and removes the connection from the state table.

8.1.3. On the Admin PC, close both the PuTTY window and the Command Prompt window that are running the connections to the PERIM router.

8.1.4. In the SSH connection to the ASA, use the show conn command again. Verify that the connections to the Perimeter Router from the Admin PC are no longer in the state table.

8.1.5. Also, use the show xlate command. The translation for the Admin PC should still be in the translation table, even though there are no connections associated with it. By default, the inactivity timeout for translation table entries is three hours. 9. Enable NAT Control on the ASA and explore the resulting connectivity:

9.1. Enable NAT Control on the ASA:

9.1.1. Using the SSH connection to the ASA running on the Admin PC, use the nat- control command to enable NAT Control:

GKL-ASA(config)# nat-control

9.1.2. Access the desktop of the DMZ Server. Attempt to use a Command Prompt window and telnet to the Perimeter Router (200.200.1.1). This should now fail. NAT Control is enabled, so connections are only allowed when explicitly defined in the configuration.

10. Remove the Identity NAT configuration on the ASA and explore the results: 10.1. Return to the SSH connection to the ASA running on the Admin PC. 10.2. Remove the nat 0 statement assigned to the inside interface:

GKL-ASA(config)# no nat (inside) 0 0.0.0.0 0.0.0.0

10.3. View the current translation table with the show xlate command:

GKL-ASA(config)# sh xlate

2 in use, 2 most used

Global 10.10.10.10 Local 10.10.10.10 Global 10.10.1.10 Local 10.10.1.10

Note The translation for the Admin PC remains, even after the nat command has been removed. Optionally, you can verify that the Admin PC can still telnet to the Perimeter Router.

Note This translation entry will timeout after 3 hours of inactivity, or it can be removed immediately with the clear xlate command.

10.4. Clear the translation table and then display it again to verify it is empty:

GKL-ASA(config)# clear xlate

GKL-ASA(config)# sh xlate

0 in use, 2 most used

Note Optionally you can verify that neither the Admin PC nor the DMZ Server can reach the Perimeter Router. NAT Control is turned on and there are no explicit NAT rules in the ASA’s configuration.

11. Return the Perimeter Router to its original state:

11.1. Return to the desktop of the Access PC and use the console connection to the Perimeter Router.

11.2. Remove the two static routes to the Perimeter Router as follows:

PERIM#conf t

Enter configuration commands, one per line. End with CNTL/Z. PERIM(config)#no ip route 10.10.0.0 255.255.0.0 200.200.1.2

PERIM(config)#no ip route 172.16.0.0 255.255.0.0 200.200.1.2

PERIM(config)#exit