Popular Tags:

Happy April Fools Day 2015 Everyone!

April 1, 2015 at 2:17 pm

I ordered mine today! Because I am a sucker for anything Apple!

Screenshot 2015-04-01 10.10.08

https://www.twelvesouth.com/hirisetoast

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

March 31, 2015 at 12:38 pm

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.

Using Objects with Access Lists

March 30, 2015 at 12:47 pm

What if you are asked to use objects in access lists. Note we are saying objects here – not object groups. The big difference is that an object can only contain a single entity. Let’s take a look at a sample configuration. In fact – let’s allow a return ping from a device on the outside like we did in earlier access list posts, but this time, we will use objects. I am using real gear in this example since my crappy little GNS3 image does not support the use of objects, only object groups.

ASA Topo

object network INSIDEHOST
 host 10.10.10.1
object network OUTSIDEHOST
 host 192.168.1.1
object service PINGREPLY
 service icmp echo-reply
access-list OUT_IN permit object PINGREPLY object OUTSIDEHOST object INSIDEHOST
access-group OUT_IN in interface outside

Sure enough – this config worked great:

Rack4R1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Rack4R1#

In fact – if you look at the access list – you see it is enumerated normally:

ASA3# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list OUT_IN; 1 elements; name hash: 0x16c2190a
access-list OUT_IN line 1 extended permit object PINGREPLY object OUTSIDEHOST object INSIDEHOST (hitcnt=0) 0x088a9534 
  access-list OUT_IN line 1 extended permit icmp host 192.168.1.1 host 10.10.10.1 echo-reply (hitcnt=1) 0x088a9534 
ASA3#

ASA Access Control Lists Basics Part 2 of 2

March 29, 2015 at 1:13 pm

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.

ASA Access Control List Basics Part 1 of 2

March 28, 2015 at 1:22 pm

In this post – we are going to create a quick ASA topology in GNS3 and have some fun with access lists basics.

Here is our topology – I will go ahead and configure OSPF everywhere so we have full reachability. I also placed X.X.X.X loopbacks on the devices that will be nice for testing purposes. I used 3.3.3.3 on the TestPC:

Screenshot 2015-03-28 08.46.12If you are wondering what those hubs are all about – I read somewhere that they are the least finicky when it comes to getting the ASA to speak to the devices on the network. I know direct connections and the Ethernet Switch in GNS3 are both buggy. I cannot wait for VIRL to feature the ASA in April 2015.

So we better start with a basic sanity check. Lets try and Telnet from the inside (R1) to the outside (R2). We expect this to work of course thanks to the inspection of TCP and UDP traffic by the ASA with its default rules in place:

R1#telnet 2.2.2.2
Trying 2.2.2.2 ... Open
User Access Verification
Password:
R2>

Well – that worked great – did the ASA inspect it? Let’s check:

ASA1# show conn detail
7 in use, 10 most used
...
TCP outside:2.2.2.2/23 inside:10.10.10.1/64631,
flags UIO, idle 57s, uptime 59s, timeout 1h0m, bytes 102
ASA1#

Yes indeed.

Now – let’s say we want R1 to be able to ping R2. This is not possible by default. Let’s punch a hole in the outside interface inbound so that ECHO-REPLY packets can make it for this specific ping.

access-list OUT_IN permit icmp host 192.168.1.1 host 10.10.10.1 echo-reply
access-group OUT_IN in interface outside

So I just did the ping on R1 (ping 192.168.1.1) and it worked perfectly, so that very specific access list did its job.

But wait a minute – didn’t we just break Telnet from the inside to the outside? That access list has an implicit deny all at the end…

I just tried a Telnet from R1 to R2 and it worked perfectly just as before. What gives?

Well – for those Reply packets for the Telnet from the inside, inspection happens first – then the ACL. So the traffic is indeed permitted in this case even with our outside access control list permitting the ping responses.

DO NOT CONFUSE ACCESS LISTS WITH INSPECTION. They are indeed two different things and it is very important to know each separately and how they operate – and then how they would react when combined.

Thanks for reading. We will take this topology and have even more fun with it in the next post.