Tag Archives: firewall

AJSnetworking.com Book Giveaway – FIREWALL Book!

firewall

I will be giving away my tech book collection here at the blog throughout the month as a thank you to my readers!

The fourth giveaway is ready – OK, OK, this exam (642-617) has been retired, but the book is still chock full of Cisco ASA goodness. Since I am one of the authors, it even comes personalized from me. That is worth at least an extra 0.10 cents.

The first reader THAT TRULY NEEDS this book for their studies to respond using the Contact Anthony link at the top of the blog will receive it. You must meet these conditions:

  • Mailing address in the continental US
  • Provide valid full name and mailing address in the email
  • Be a good person 🙂
  • Have not received a free gift from this site prior to this giveaway

I am so glad I can help you with your studies!

“New” NAT on the ASA – Object NAT/PAT with Manual Config

There are so many variations that are possible with NAT now – and I am just talking in the “new rules”. In this post, lets just review one. We will do dynamic NAT with a PAT backup using network objects. We will provide the NAT instructions manually instead of inside an object.

Our topology is as follows:

ASA NAT

Our objective here is as follows:

  • Configure NAT so that hosts on the inside network 192.168.65.0/24 attempting to reach the outside network are translated using the pool 74.0.0.102 to 103. We need to use the interface IP address as a PAT backup. The NAT configuration must be manual.

My first step is to create my network objects:

object network 192INSIDE
 subnet 192.168.65.0 255.255.255.0
object network POOL1
 range 74.0.0.102 74.0.0.103

Verification of this step is show run object.

Now I am ready for the manual NAT:

nat (inside,outside) source dynamic 192INSIDE POOL1 interface

The above command is made VERY easy thanks to context-sensitive help.

For verification – we do not even need to leave the ASA thanks to Packet Tracer!

packet-tracer input inside tcp 192.168.65.3 1027 4.4.4.4 23
...
Phase: 4      
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (inside,outside) source dynamic 192INSIDE POOL1 interface
Additional Information:
Dynamic translate 192.168.65.3/1027 to 74.0.0.102/1027
...
Result:       
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
ASA1# 

Of course, we can always create traffic through the ASA and view the translation. Here I telnet through from R3 on the inside to R4 on the outside. We confirm out configuration and that traffic is matching it:

ASA1# show nat
Manual NAT Policies (Section 1)
1 (inside) to (outside) source dynamic 192INSIDE POOL1 interface  
    translate_hits = 6, untranslate_hits = 6
ASA1#

Of course I will be back with plenty of other “new” NAT sample configurations and verifications for you.

ASA Access Control Lists Basics Part 2 of 2

This is a follow up to our previous post – please check that one out as we are going to pick up right where we left off.

Screenshot 2015-03-28 08.46.12

Let’s now add an outbound access list on that outside interface and see if we do indeed start to break other types of access through the ASA. We will create one that permits Web traffic outbound:

access-list OUT_OUT permit tcp host 10.10.10.1 host 192.168.1.1 eq www
access-group OUT_OUT out interface outside

Now we just created a bit of a nightmare. Telnet is indeed broken from the inside as it is hitting this access list and getting dropped:

R1#telnet 2.2.2.2
Trying 2.2.2.2 ...
% Connection refused by remote host 
R1#

We can certainly see why it is most common to use inbound access lists on the ASA.

Now Cisco understands that this can all get a bit confusing…inspection, access-lists, access-list direction…so they provide a very powerful tool on the ASA to help you in troubleshooting. The Packet Tracer.

In our previous post – we said that R2 should be able to respond to pings from the inside. We chose to test that by actually going to the device (R1) and initiating the ping. But we could have stayed right on the ASA and confirmed things with Packet Tracer as follows:

ASA1# packet-tracer input outside icmp 192.168.1.1 0 0 10.10.10.1
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.10.10.0      255.255.255.0   inside
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUT_IN in interface outside
access-list OUT_IN extended permit icmp host 192.168.1.1 host 10.10.10.1 echo-reply 
...
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
ASA1#

Another powerful tool you can utilize if you are troubleshooting your access lists on the ASA is logging. In our case, the results of our packet tracer above show that the ECHO REPLIES from R2 will be permitted, but of course we have an access list outbound on the outside interface that will actually drop the ECHO packets. In order to see this, I will enable logging and send the results to the console and then try our ping…

ASA1(config)# logging on

ASA1(config)# logging console 7

So now, this is what shows up on the ASA when we try the ping:

%ASA-4-106023: Deny icmp src inside:10.10.10.1 dst outside:192.168.1.1 (type 8, code 0) by access-group "OUT_OUT" [0x0, 0x0]

We love this kind of reporting, letting us know exactly why R1 can no longer ping R2!

I hope you enjoyed this two part series on basic access list usage on the ASA.