Tag Archives: 5585-X

You, Me and NAT 8.3

Leave a reply

NAT on ASA 8.3 and higher

It is important to know that the change from 8.2 to 8.3 was massive. It did divide ASA users to a point some felt cheated or disheartened by Cisco’s actions. I admittedly picked it up rather quickly though others who are been using the family for years had a tougher time. The biggest change comes in the syntax. ASA 8.3 and higher leverages the use of object-orientated configuration which allowed the overcoming of 8.2 caveats. The biggest bonus is the ability to scale firewall rule bases. Other features such as the keyword any, defining translations as objects, and ACL, MPF, AAA features matching the real/un-translated address.

Order of Operations – 8.3 and higher ASA

  1. Manual NAT
  2. Auto NAT
  3. Manual NAT after Auto

It is important to understand that NAT translations are now treated much like an access-list. It is best to place the most specific rules at the top and lease specific towards the bottom.

Configuring Auto NAT – 8.3 ASA

This new version of NAT is easiest to configure. It also goes by the name of Object NAT. There are three types of auto NAT configurations.

  1. Static NAT – one to one translation for static hosts. Adds in  a permanent connection entry.
  2. Dynamic NAT – allows multiple uses of single pool of addresses. PAT is used when address pool is full.
  3. Dynamic PAT – allows multiple addresses to use one or more  translated addresses simultaneously.

Auto NAT – Static NAT – 8.3 ASA

The configuration of Static NAT in the 8.3 software is very different but very scalable.

object network internal-mail
host 192.168.16.23
object network internal-mail-outside
host 203.66.23.84
object network internal-mail
nat (inside,any) static internal-mail-outside

Here we define two objects. internal-mail and internal-mail-outside with their respective IP addresses. We then define under internal-mail the NAT we want to take place. The ASDM configuration window resides at Configuration > Firewall > Objects > Network Objects/Groups.

Auto NAT – Dynamic NAT – 8.3 ASA

Dynamic Translations of NAT in 8.3 again utilize objects. A subnet is defined here opposed to a 1:1 mapping of addresses like static NAT.

object network 172.16.23.0_NET
subnet 172.16.23.0 255.255.255.0
nat (inside,outside) dynamic interface

The object we define in this part is actually an entire subnet. We are allowing the subnet 172.16.23.0/24 to be natted to the IP address of the outside interface. This type of NAT is generally what is applied to an end-user subnet. The ASDM configuration window resides at Configuration > Firewall > Objects > Network Objects. Select Network Object from the dropdown. When filling out the information it is important to tick Add Automatic Address Translation Rules.

Manual NAT – 8.3 ASA

Manual NAT takes precedence over auto NAT in the translation table. Manual NAT can also be configured to be processed after auto NAT. This allows for a fall back scenario and deterministic failover. It can be configured on both source and destination IP addresses; this is known as Twice NAT.

object network 10.10.1.0_NET
subnet 10.10.1.0 255.255.255.0
object network 65.242.123.97_outside
host 65.242.123.97
object network 184.63.22.23_MAIL
host 184.63.22.23
nat (inside,outside) source dynamic 10.10.1.0_NET 65.242.123.97_outside destination static 184.63.22.23_MAIL 184.63.22.23_MAIL

So what is happening here? First we begin by translating packets from the inside to outside with (inside,outside). Source dynamic translate the source IP with dynamic translation. 10.10.1.0_NET 65.242.123.97_outside will translate source IP packets defined in the object 10.10.1.0_NET to global addresses defined by the object 65.242.123.97_outside. Destination static defines destination IP translation as static and the object 184.63.22.23_MAIL is the destination IP that is set to not be translated.

The ASDM configuration window resides at Configuration > Firewall > NAT Rules > and select the Add NAT Rule Before “Network Object” NAT dropdown.

Twice NAT – Source and Destination NAT

There are occasions where RFC 1918 addresses overlap. When they do Twice NAT has its place. Lower ranges in this address space are commonly used by all kinds of networks; Twice NAT can be configured to avoid this.

object network INSIDE-CUSTA-NET
subnet 192.168.1.0 255.255.255.0
object network 192.168.10.11_PAT
host  192.168.10.11
object network 192.168.10.0_NET
network 192.168.10.0 255.255.255.0
object network 192.168.11.0_NET
network 192.168.11.0 255.255.255.0
nat (inside,CUST_A) source dynamic INSIDE-CUSTA-NET 192.168.10.11_PAT destination static 192.168.1.0_NET 192.168.11.0_NET




After defining our objects we then apply the NAT statement. The traffic that now flows from the interface inside to CUST_A is now subject to translation rules. The dynamic source of the translation is the object network INSIDE-CUSTA-NET to network defined by 192.168.10.11_PAT. Destination static will translate the destination IP address using static translations. 192.168.1.0_NET 192.168.11.0_NET will translate addresses that are defined by 192.168.11.0_NET to addresses defined by 192.168.1.0_NET.


The ASDM configuration window resides at Configuration > Firewall > NAT Rules > and select the Add NAT Rule Before “Network Object” NAT dropdown.


Manual NAT after Auto NAT – 8.3 ASA


This type of NAT allows for translations after not meeting the criteria of more specific matches.


nat (any,outside) after-auto 1 source dynamic 192.168.16.0_NET 203.86.14.0_NET_OUT


The biggest difference in this command is the after-auto. This is what sets it to translate after auto NAT has been processed. The ASDM configuration window resides at Configuration > Firewall > NAT Rules > and select the Add NAT Rule After “Network Object” NAT dropdown.


Directional NAT


Directional NAT translations are based upon the direction of the request. If the source object that is defined makes a request it is only translated once. By default a NAT translation occurs both ways.


nat (inside,dmz14) source static MAIL-14-INT MAIL-14-EXT unidirectional


The keyword unidirectional is what allows this function to take place. The ASDM configuration window resides at Configuration > Firewall > NAT Rules > Edit NAT Rule.


NAT Caveats


It is important to know where NAT can be used and where NAT will cause headaches. The list below is situations where NAT will cause you to have a bad day.


    

  • Embedded IP addressing
    • 

  • End-to-end encryption
    • 

  • Authenticated IP packets

      

    • IP headers
      • 

    • TCP headers
      • 

    • IPSEC
      • 

    

    • 

  • 8.2 ASA NAT changes configuration of ACL, AAA, MPF due to the fact 8.2 references the post-NAT IP.
    • 


					

		
		
	


	

				

									

				NATing like it’s Nineteen Ninety Nine
			

										

					Leave a reply				

					


				

			
–Network Address Translation, ASA 8.2


NAT is required for a number of scenarios and can be used in the most unusual places. Most common is translation of a private RFC 1918 address into a globally routed public IP address. An example of this would be a home device with an address of 10.10.16.10 being translated to 200.165.231.20 when going to the internet. The translation table keeps a record of this conversation and then when the destination packet returns to 200.165.231.20 it is sent back to the device it originated from – 10.10.16.10. There are a number of different NAT styles and syntax styles. Syntax changes between 8.2 and 8.3 caused commotion among ASA users. This section will clearly state which NAT method is being used.


Order of Operations – 8.2 ASA


The interface order of operations is important to understand where NAT takes its place in connection criteria.


    

  1. NAT Exemption
    2. 

  2. Static NAT and Static PAT
    3. 

  3. Policy Dynamic NAT
    4. 

  4. Regular Dynamic NAT
    5. 

  5. NAT Control on and no match will drop packet
    6. 



Dynamic NAT – 8.2 ASA


Dynamic NAT will translate an IP address into a pre-defined pool of addresses for communication. Generally this is employed in a situation of higher security to lower security. An address is generally reserved for PAT in case the pool defined fills.




nat (inside) 1 10.10.10.0 255.255.255.0


global (outside) 1 192.168.20.15-192.168.20.150


global (outside) 1 192.168.20.151




The above example of 8.2 Dynamic NAT will take addresses from the inside source range of 10.10.10.0/24 and translate them to an address on 192.168.20.15-150 range. This occurs when traffic goes from inside to outside. If the translation pool fills the 192.168.20.151 address is there to perform PAT.


The ASDM configuration window resides at Configuration > Firewall > NAT Rules. Then select Add Dynamic NAT Rule.


Static NAT – 8.2 ASA


Static NAT’s recommended use is where an application based server needs to be accessed from an external network. Due to a translation is always present in the table, remote connections can establish. It is best used when connections need to be established from an outside interface which has a lower-security level than the host being accessed. The addresses listed are what we will use for our example. The server has an internal address of 192.168.16.10 on interface dmz-mail and outside requests hit 202.16.142.30 on interface isp-a.




static (dmz-mail,isp-a) 202.16.142.30 192.168.16.10




A good way to remember static 8.2 NAT is the following structure defined in the table below.






Real IP
Mapped IP
Mapped IP
Real IP




dmz-mail
isp-a
isp-a
dmz-mail






 


The ASDM configuration window resides at Configuration > Firewall > NAT Rules. Then select Add Static NAT Rule.


Static Exemption, Exemption and Identity NAT – 8.2 ASA


The following examples are devices that do not need NAT translations to take place.


Static identity NAT creates a slot in the translation table as it is configured.




static (dmz-c,outside) 206.100.100.42 206.100.100.42 netmask 255.255.255.255




Dynamic identity NAT will create a dynamic identity in the translation table. This is where the local and global addresses are the same. Used when clients access less secure interfaces.




nat (inside) 0 10.36.100.0 255.255.255.0




Remember that a pool ID of 0 is a specific command to the ASA software not to translate.


Finally is NAT exemption. This mode behaves differently due to the fact it bypasses NAT operations in the Order of Operations.




nat (inside) 0 access-list CI-VPN




The ASDM configuration window resides at Configuration > Firewall > NAT Rules. Then select Add Static NAT Rule. Ensure NAT Exempt Outbound Traffic from Interface “inside” to Lower Security Interfaces (Default) is enabled for Exemption.


NAT caveats for 8.2


NAT control was a feature of 8.2. It ensured that NAT rules had to be in place when enabled; Traffic would be dropped if no translation rule was found. NAT exemption was the other way for traffic to traverse a firewall when NAT control was enabled. This did lead to excess configuration on the firewalls. In ASA 8.3 this feature was removed completely. If a connection cannot find a translation it is allowed and is subject to other access policies.

					

		
		
	


	

				

									

				Routing to a wall of fire
			

										

					Leave a reply				

					


				

			
–Routing on ASA–


The ASA supports static and dynamic routing protocols. As of ASA code release 8.3+ most routing protocols are supported. OSPF, EIGRP, RIPv2, and static routing are the protocols the ASA can use.


Static Routes


Static routes are entries in the routing table that will forward traffic to a different network. These are great for deployment in an environment where network traffic is predictable.




route outside 10.86.42.0 255.255.255.0 192.10.14.1




This route will send traffic with a source subnet of 10.86.42.0/24 to the outside named interface destined with a next hop IP of 192.10.14.1. Default administrative distance is 1. This can be changed by adding a different value to the end of the route.




route outside 10.84.42.0 255.255.255.0 192.10.14.1 15




This would change the static routes administrative distance to 15.


Default Route


Default routing is dirty. I will be honest that I do not like it as you should have control over what is in your routing table. Anyway, to configure




route outside 0.0.0.0 0.0.0.0 203.16.84.66 


route outside 0 0 203.16.84.66


route outside 0 0 203.16.84.66 distance 5




The above are three ways of implementing a default route. The first is if a more specific route is not found in the routing table to send any network any mask to 192.168.10.14. The second entry is mainly for reasons of brevity; the 0 represents 0.0.0.0. The third entry uses the brevity statement and alters the administrative distance to 5.


Here is some output of the examples above by issuing the show route command.




ciscoasa(config)# sh route


Gateway of last resort is 203.16.84.66 to network 0.0.0.0


C    203.16.84.0 255.255.255.0 is directly connected, outside
 S    10.84.42.0 255.255.255.0 [15/0] via 192.10.14.1, outside
 C    192.168.2.0 255.255.255.0 is directly connected, inside
 S*   0.0.0.0 0.0.0.0 [1/0] via 203.16.84.66, outside




The static route denoted with an S is the route we manually defined. Also notice the adjusted the administrative distance on to 15. Note that the S* route is the candidate default route. Any network that doesn’t have a match before this route is immediately forwarded to the outside interface with the next hop set as 203.16.84.66.


RIP Routing


RIP routing is basic distance vector routing. It uses hop count for its metric and is slow to converge. It is subject to split horizon rules and is designed for small networks. Below we will confirm that we have received routers with the show route command on the ASA firewall.




ciscoasa# sh route


Gateway of last resort is not set


C    1.1.1.0 255.255.255.0 is directly connected, Management
 R    192.168.0.0 255.255.255.0 [120/1] via 192.168.2.2, 0:00:01, inside
 R    192.168.1.0 255.255.255.0 [120/1] via 192.168.2.2, 0:00:01, inside
 C    192.168.2.0 255.255.255.0 is directly connected, inside
 R    192.168.3.0 255.255.255.0 [120/1] via 192.168.2.2, 0:00:01, inside




Note that the R indicates a RIP route. Administrative distance is 120 which is default for RIP.


EIGRP Routing


EIGRP routing is very similar to IOS devices. It is configured to behave the same way; it routes the same way due to being a Cisco proprietary protocol.




router eigrp 1


network 192.168.2.0 255.255.255.0


no auto-summary




With the above configuration the inside network interface has formed an adjacency with one of the core routers. It is important to issue no auto-summary as with EIGRP auto summary is enabled by default. This command will allow subnet masks to be passed with routing updates.


The ASDM configuration window resides at Configuration > Device Setup > Routing > EIGRP.


To confirm this we issue a show route.




ciscoasa# sh route


Gateway of last resort is 203.16.84.66 to network 0.0.0.0


D    172.16.26.0 255.255.255.0 [90/156160] via 192.168.2.2, 0:00:01, inside
 D    172.16.20.0 255.255.255.0 [90/156160] via 192.168.2.2, 0:00:01, inside
 D    172.16.23.0 255.255.255.0 [90/156160] via 192.168.2.2, 0:00:01, inside
 C    203.16.84.0 255.255.255.0 is directly connected, outside
 S    10.84.42.0 255.255.255.0 [15/0] via 192.10.14.1, outside
 C    192.168.2.0 255.255.255.0 is directly connected, inside
 S*   0.0.0.0 0.0.0.0 [1/0] via 203.16.84.66, outside




Note the routes with a D in the routing table. These have been learnt by our core router. A quick issue of show eigrp neighbors reveals some peering info.




ciscoasa# show eigrp neighbors


EIGRP-IPv4 neighbors for process 1


H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq(sec)


0   192.168.2.2             Gi0              11  00:05:14 1860 5000  0    2




 


OSPF Routing


OSPF is a widely deployed, open standards protocol which uses link state algorithms and shortest path first technologies. Again, like EIGRP, its deployment on an ASA device is the same as IOS. The only funny caveat is that it does not use a wildcard mask unlike so much other implementations.




router ospf 1


router-id 1.1.1.10


network 192.168.2.0 255.255.255.0 area 0




As I said before it is odd that the wildcard mask isn’t used. It isn’t a big adjustment.


The ASDM configuration window resides at Configuration > Device Setup > Routing > OSPF.


Now to confirm the adjacency let us check our OSPF neighbor relationship. First command to check the OSPF database is show ospf database




ciscoasa# show ospf database


OSPF Router with ID (1.1.1.10) (Process ID 1)


Router Link States (Area 0)


Link ID         ADV Router      Age         Seq#       Checksum Link count


1.1.1.1         1.1.1.1         142         0x80000002 0x7d75 3


1.1.1.10        1.1.1.10        141         0x80000002 0xb87c 1


Net Link States (Area 0)


Link ID         ADV Router      Age         Seq#       Checksum


192.168.2.2     1.1.1.1         142         0x80000001 0x783f




Here we can see the database exchanging type 1 and 2 LSAs between Router 1 and ASA1. ASA1’s router ID is 1.1.1.10 and R1’s is 1.1.1.1. With the LSA exchange complete we can check our neighbourship with show ospf neighbor




ciscoasa# show ospf neighbor


Neighbor ID     Pri   State           Dead Time   Address         Interface


1.1.1.1           1   FULL/DR         0:00:34     192.168.2.2     inside




We can see the neighbor router ID, the state is Full/DR (Designated Router) and the interface address it has and which interface we are receiving it on. The final command to confirm routes in our routing table is show route.




ciscoasa# show route


Gateway of last resort is 203.16.84.66 to network 0.0.0.0


C    203.16.84.0 255.255.255.0 is directly connected, outside
 S    10.84.42.0 255.255.255.0 [15/0] via 192.10.14.1, outside
 O    192.168.51.1 255.255.255.255 [110/11] via 192.168.2.2, 0:00:29, inside
 O    192.168.50.1 255.255.255.255 [110/11] via 192.168.2.2, 0:00:29, inside
 C    192.168.2.0 255.255.255.0 is directly connected, inside
 S*   0.0.0.0 0.0.0.0 [1/0] via 203.16.84.66, outside




Fantastic! Here you see the routers with the O next to them. These are routers learnt via OSPF. Note their administrative distance of 110 is OSPF’s default.


Multicast Routing


Multicast network traffic is the quiet achiever. It is taken for granted when so many of our current applications leverage it. It is great for scalability and delivers traffic efficiently in one to many situations. The ASA appliance can be either a IGMP proxy or a PIM-SM Rendezvous point. By default, multicast routing is disabled on the ASA.




multicast-routing




The CLI command above will enable multicast routing globally.The ASDM configuration window resides at Configuration > Device Setup > Routing > Multicast. Select Enable Multicast Routing. Once multicast routing has been enabled you can configure other multicast options. To enable IGMP forwarding issue the following command.




igmp forward interface dmz20




The ASDM configuration window resides at Configuration > Device Setup > Routing > Multicast > IGMP > Protocol. Select which interface you want to enable it on.

					

		
		
	


	

				

									

				Transparent and Routed ASA basics
			

										

					1 Reply				

					


				

			
–Transparent and Routed Firewalls– 


There are two modes in which you can have your firewall; routed or transparent mode. Each mode will treat the packets differently and operate in its own way. Depending on your requirements of your design you will choose what is best for you. On the release of ASA 9 it is important to know that in each context can be placed in either firewall mode. Before 9.0 code you had to consider your overall design as the mode was persistent across all contexts.


Routed Firewall


The routed firewall is the default mode for an ASA firewall. It acts as a layer 3 device and is a routed hop; this acts in the same way as a router would. It uses routing protocols and static routes. Forwarding is down with destination IP addresses.


Transparent Firewalls


Transparent firewalls are known as Bumps in the Wire. They work purely at layer 2 and is not seen as a hop; opposed to layer 3 routed firewalls which decrement TTL. By bridging interfaces the ASA can forward traffic transparently to the end user/device. It is important to remember there are limitations to transparent firewalls in its capabilities and to keep this in mind when designing networks with Cisco ASA firewall. Forwarding is done with destination MAC addresses.


Features that are not supported are:


    

  • QoS
    • 

  • DHCP relay

      

    • Cannot be a DHCP server but can pass relay      commands with extended ACL
      • 

    

    • 

  • VPN termination

      

    •  only site-to-site VPN for management is supported.
      • 

    

    • 

  • Extended ACLs can pass connections.

      

    • SSL VPN is not supported.
      • 

    

    • 

  • Dynamic/Multicast Routing

      

    • Need ACL to pass traffic.
      • 

    

    • 

  • Dynamic DNS
    • 



Since 8.02 NAT can be performed in transparent mode. This gives more control over traffic. The same rules also apply regarding interface security levels; higher security interfaces can traverse lower security interfaces by default.


To configure the transparent firewall the following needs to occur. Enable transparent firewall, configure bridge group, and configure management.


To set the firewall in transparent mode issue the following




firewall transparent




This will immediately restart the firewall. It is wise to save any existing configuration to memory in case a rollback is required. After the reboot your firewall will be in transparent mode.


Next configure the Bridged Virtual Interface and assign interfaces to the group.




interface BVI1


ip address 192.168.1.1 255.255.255.0


int gi0/1


nameif inside


bridge-group 1


security-level 100


no shut


int g0/2


nameif dmz20


bridge-group 1


security-level 50


no shut




It is important to be aware that the address assigned to the BVI is the management IP. This address will not be seen by traffic transiting across the ASA. Each bridge group can support four interfaces whilst each context can have eight bridge groups. We will discuss contexts later.


The configuration of a static route is to ensure reachability of the management BVI. It is also needed if NAT is being performed or VOIP traffic inspection is enabled.


Transparent Access Rules


Transparent access rules are the same as routed mode. ARP traffic can pass either way through interfaces. It is important that in transparent firewall mode that you use interface ACLs to allow broadcast and multicast traffic.


To allow broadcast traffic will permit protocols such as DHCP, EIGRP, OSPF, RIP, and HSRP to pass through the firewall. An example would be creating an ACL that supports EIGRP. You would require on each interface a permit statement allowing port 88 with the broadcast IP of 224.0.0.10 to enable EIGRP support. Alternatively you can apply this globally.




object-group network EIGRP_MCAST_ADD


network-object host 224.0.0.10


access-list EIGRP extended permit eigrp any object-group EIGRP_MCAST_ADD


access-group EIGRP in interface inside


access-group EIGRP in interface outside




The ASDM configuration window resides at Configuration > Firewall > Access Rules > Add Access Rule.


Thoughts


Depending on the situation the use of transparent or routed firewalls was critical in the design and deployment of ASA firewalls. Scoping and application of placement and requirements is critical to selection of the correct model of firewall. I like the ASA family of firewalls and what they can do and deployment of contextual firewall modes adds to its feature set. It is a shame that licensing can cripple the real use of this technology.


 

					

		
		
	


	

				

									

				Why hate on ASA?
			

										

					15 Replies				

					


				

			
The Cisco ASA line has some serious bad juju when mentioned in networking circles. Example of this is of my mentor, Kurt Bales. He is a Juniper champion, JNCIE candidate, and all around network guru. His background lent it self to best tool for the job mentality. Yet with that mindset – there is hate. Don’t think this musk stick loving engineer is alone. There are others who concur and agree.




That being said, I think I am sick of it. I want to share my experiences with a platform I believe is stable, robust, and deserves a place in your next upgrade and deployment.


Bad juju or haters gunna hate?


Is the ASA such a terrible platform or are the haters who hate on ASA do so unjustifiably? In a recent installation of 6 x 5585-X SSP-10 I have been through the entire PPDIOO life cycle. I planned, prepared and designed. I assessed our needs.


    

  • Virtualize the core.
    • 

  • Establish multiple VRFs and VPNs to many sites.
    • 

  • Allow third party access with very particular rule sets.
    • 

  • Establish multi-site failover to partner services whilst sustaining sessions.
    • 

  • Establish access control and ease of management.
    • 

  • Predictable traffic patterns.
    • 



I needed throughput and rule set grunt. The fact that 2 x 10GBE connections will be sitting at a moderate utilization was a factor.


The ASA delivers on this and more. Not once in any of our tests could we load it up enough. Failover with HA technologies were flawless. The ability to control our traffic to meet the security requirements that we had in place were met. Load balancing via context loading was important and achieved. Management via CLI/ASDM as phase 1 before moving to CSM was a benefit. I am pushing some serious traffic through this and have more than a paltry need. The environment I am in cannot tolerate downtime nor fault


I am not blind


I know there are shortcomings of the platform. Some may argue that the ASA code is years behind. Some gripe that ASDM doesn’t work on OSX due to java. (I agree Java is so-so). Juniper do have some rock solid offerings that can do features that ASA cannot. BGP routing, DHCP reservation, just to name a few.


As ASA 9.0 approaches (I have been told it isn’t vaporware) the playing field between code features that Juniper offer should be leveled. It pairs it back to a hardware battle. What that means to you? Sound high availability. Great failover. Sound build and quality. Cisco reliability that has made them the number one networking company.


Tool for the job


The right tool for the job needs to be adopted. In the plan and prepare phases you need to assess the requirements of what will traverse the firewall. What functions need to be performed and how it will do it?  Service contracts and maintenance. Who can provide you with that? Professional services if you used managed services? Are they proficient with the platform? In house skill sets are also important to consider if training budgets or ability of staff is a concern. With these things in mind then finding the right firewall in the ASA family can be achieved.


As Kurt said, candidate config and commit confirmed would be nice. Just a small software nice to have which can always be added at a later day.


Vote 1 ASA


I think the ASA family needs to be considered in your designs. The hardware is sound. Cisco are a Tier 1 vendor. The code, albeit missing some feature, is stable. I am a very happy customer of the ASA family and this top end model for me has nothing but delivered.


 

					

		
		
	


	

				

									

				LAB – NTP setup on ASA
			

										

					1 Reply				

					


				

			
The importance of time should not be under estimated. NTP allows synchronisation of clock information across your network. I am labbing my ASA inside GNS3 and want to set up a router to be the Timekeeper! The idea of this firewall and IDS is to effectively deal with threats. It is paramount that time is synchronized amongst our devices for investigative reasons.


My Security lab


Requirements


    

  • Define NTP server on R1
    • 

  • Define an NTP key with the number 10
    • 

  • Set password as Cisco
    • 

  • Use MD5 encryption
    • 




	
		Show Lab Answers	
	

		


Now let us set the time. I work in AEST due to the fact I live in Melbourne so we need to add +10. Remember to set the Time initially to UTC because we will add our timezone




clock set 1:52:00 28 May 2012
ntp master 2
ntp authentication-key 10 md5 ciscoinferno
ntp trusted-key 10


clock timezone AEST +10 0

May 28 01:52:50.695: %SYS-6-CLOCKUPDATE: System clock has been updated from 01:52:50 UTC Mon May 28 2012 to 11:52:50 AEST Mon May 28 2012, configured from console by console.




Now that we have defined the source of our time we can set up where the ASA will reference the time! Note that we first define NTP server then the source interface. We them match the authentication keys as requested by the brief. Timezone is also set locally and not passed via NTP.




ntp server 192.168.4.2 source INSIDE
ntp authenticate
ntp authentication-key 10 md5 ciscoinferno
ntp trusted-key 10
clock timezone AEST +10 0




Now it may take a couple of minutes for synchronization to occur. Issue show ntp associations on the ASA.




ASA1# sh ntp association
 address ref clock st when poll reach delay offset disp
*~192.168.4.2 127.127.7.1 2 28 64 377 18.3 -28.06 53.9
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured





	




					

		
		
	


	

				

									

				GNS3 and Cisco ASA 8.4 (Part 2)
			

										

					8 Replies				

					


				

			
Alright! Bam! Excited? I surely am. Cisco ASA on my laptop and I can lab anywhere!  Now lets establish more than console access via GNS3 and get SSH/HTTPS/ASDM running. The reason I am so pushy to get ASA on a device is because certification guides all show how to do a task both ways. Handy in my opinion. Plus it doesn’t hurt for study reasons!

Requirements


    

  • tftpd32 – TFTP application
    • 

  • Legal version of ASDM 8.4.2 – Pretty GUI for the ASA
    • 

  • Administrator Rights – Need to bridge your interfaces!
    • 



Setup GNS3 for a host


Before we go making SSH access we need to connect our device into GNS3. Simple enough but can be daunting for some. I currently use Windows 7 on my lab machine due to the speed of spinning up VMs and the easy of connecting them in. I have dabbled with taps in Linux and it hurts my face and wastes my labbing time.


To connect your host to GNS3 I made a bridge interface with a pre-existing VM interface and my Gig Ethernet interface of my laptop.


    

  1. Open up network connections
    2. 

  2. Select Ethernet connection and VM Connection
    3. 

  3. Right Click > Bridge Connection
    4. 

  4. Assign an IP address to your device.
    5. 





Think Smart and It’s simple!


Now that we have created this adapter and assigned this address ( other end is g0 on the ASA – 192.168.2.1 ) we can create a magical unicorn (cloud) link!




    

  1. Open up GNS3 – Drag a cloud next to your ASA and place an Ethernet Switch down too.
    2. 

  2. Right click on the cloud and configure. Select the MAC address bridge and add that connection.
    3. 

  3. Cable the cloud to the switch and then the switch to the ASA
    4. 



Pick the right interface lest their be judgment most Righteous


 


Back to the ASA!


Now lets get some initial configuration on this ASA and get connectivity from our Windows machine! We are getting there people! Slow and steady wins the race.


Note: GNS3 lists interfaces as E0-5. The ASA sees them as G0-5.


Alright – Basic ASA configuration and required Interfaces




interface GigabitEthernet2
 nameif MANAGEMENT
 security-level 0
 ip address 192.168.2.1 255.255.255.0
username asa password xGIkoVq88G4kwjuv encrypted privilege 15






Now to make the SSH keys




domain name ciscoinferno.net
crypto key generate rsa
ssh 192.168.2.0 255.255.255.0 MANAGEMENT
aaa authentication ssh console LOCAL
ssh timeout 5




Voila! Subnet 192.168.2.0 from the Management interface has been allowed for SSH. Now to test a ping from the 192.168.2.2 host and then connect via SSH!




C:\Users\CiscoInferno>ping 192.168.2.1
Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=4ms TTL=255
Reply from 192.168.2.1: bytes=32 time=1ms TTL=255
Ping statistics for 192.168.2.1:
 Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 1ms, Maximum = 4ms, Average = 2ms






Looky Looky – SSH keys


and one day…. I got in


Now let’s TFTP the ASDM software from 192.168.2.2 onto the ASA at 192.168.2.1. Rather simple process. TFTD32 is installed onto the host at 192.168.2.2 and the file ASDM-641.bin is in the tftp root.




ASA1# copy tftp disk
Address or name of remote host []? 192.168.2.2
Source filename []? asdm-641.bin
Destination filename [disk]?
Accessing tftp://192.168.2.2/asdm-641.bin...!!!!!!  !!!!!!!
15841428 bytes copied in 41.550 secs (386376 bytes/sec)
ASA1#




Installed. Now we just enable the HTTPS web service and off we go. So close! Study can almost begin!

The commands to set up the HTTPS web server are not far away and very similar to the SSH syntax.  We first enable the service then allow what subnet on which interface to access it.




http server enable
http 192.168.2.0 255.255.255.0 MANAGEMENT
aaa authentication http console LOCAL






Let’s save this as a basic config.






copy run start
copy start disk


<span class="Apple-style-span" style="font-family: Georgia, 'Times New Roman', 'Bitstream Charter', Times, serif; font-size: 13px; line-height: 19px; white-space: normal;"><span style="text-decoration: underline;">ASDM Access time</span></span>




Now we open up Internet Explorer (Chrome went funky chicken on me) and lets browse to https:\\192.168.2.1 and see what happens.


 


Here we go!


Now – let us login via ASDM and use the web gui! Click Run ASDM.  After some loading check out what will appear next!


Jobs done!


And with that we have working ASDM! Now go forth and spread the good work. Let me know how you have found this post and I will attempt to help those below who cannot get this working. Again I will not give out any software illegally. Happy Labbing!


Previous Post GNS3 and Cisco ASA 8.4 (Part 1)

					

		
		
	


	

				

									

				GNS3 and Cisco ASA 8.4 (Part 1)
			

										

					21 Replies				

					


				

			
GNS3 has been a stable to my personal study. When I first achieved ROUTE on my way to CCNP I worked in a heavily switched environment. I had worked on routers and routing technologies about 5 percent of the time. It wasn’t enough to brush over the material and blitz the exam. I required a deep dive into the materials offered. I ended up using GNS3 and could create multi-area OSPF topologies, Giant EIGRP networks, and BGP with cheeky redistribution. This was only the beginning.


Imagine this inside your laptop and access anywhere?


My current place of employment is about to have ASA’s come out of the nether regions. 5585-CX is the flavour of the day. As a part of all this I am being sent to a Cisco partner course covering FIREWALL topics. I guess this aligns with the CCNP Security FIREWALL  curriculum. My ASA exposure is quite limited and I have to admit that I generally a fish out of water when it comes to hardcore security.


I have read around about people getting PIX firewalls working with GNS3 but PIX is old! ASA took over before I even got into networking. As the new CCNA Security is now adding ASA to the course (less rubbish, more content!) and CCNP Security requires ASA/IPS and ASDM. I couldn’t afford to buy ASA devices and or the required licensing. Luckily I gained access legally to licences and ASA IOS and ASDM.


I am an advocate of licensing and doing the right thing. DO NOT ask me for links to files or for a one off link. CCO login will more than let you know if you are eligible to be using the software detailed in this article. I could be breaking the rules as it is.


 


GNS3


Let me first start this off by disclaiming that this post is not a “Welcome to GNS3″. I am expecting a level of knowledge already present and will NOT be covering basics in this post.


The version of GNS3 that this laptop is using 0.82-BETA2. I’ve not updated for a while but this is the version that works for me. Included in the All in One installer is QEMU. QEMU is the hero and emulator of the ASA software.


ASA


* If you do not have any of the required files along the way I suggest that you use the googles a little. You may find the files required.


Now – lets point GNS3 towards our ASA software. I am using 8.4.2 ASA code.


    

  1. Edit
    2. 

  2. Preference
    3. 

  3. QEMU
    4. 

  4. ASA
    5. 





QEMU settings work for me. They may not for you.




Note the picture above. The following settings are input into the fields.


ASA SETTINGS


    

  • Name: ASA8.4 (can be anything)
    • 

  • RAM: 1024MB
    • 

  • NICs: 6
    • 

  • NIC model: e1000
    • 

  • Qemu Options: -vnc none -vga none -m 1024 -icount auto -hdachs 980,16,32
    • 



ASA SPECIFIC SETTINGS


    

  • Initrd: Location of Initrd file
    • 

  • Kernel: Location of Kernel (ASA) software
    • 



Probably the most important field is below. This exact string works for ASA code 8.4 and nothing prior.


    

  • Kernel CMD: Kernel cmd line: -append ide_generic.probe_mask=0×01 ide_core.chs=0.0:980,16,32 auto nousb console=ttyS0,9600 bigphysarea=65536
    • 



Wall of Fire


Now add that and close the window. Next step is to drag across an ASA into the topology. This is my topology I am using to create my virtual lab.


My Security lab


Now just hit console and you will get the ASA to start. It will load up and it can take a while the first time. Due to the requirements being high if your CPU spikes or RAM is maxed expect it to be a poor experience. My laptop rocks 16gb ram and a sandy bridge i7 so I do not have many issues.


Hardware requirements are of particular concern if you are using Virtual Machines such as Security Onion also. IF they are a concern then just worry about connecting your client up!


Licence to kill


As we all know ASA licensing is intense. Stupidity comes to mind. Want VLANs? We got a licence for that. Want fail over? Got a licence for that? 10GBE on 10GBE hardware? Yes, my word you need licence for that.


Well the same goes for our ASA we have running. It is now a fully functioning ASA – same rules apply. Though that being said I do use a legit ASA licence – I have sourced one for you floating around the internet. From what I have read the people who made all this work got this key working . Until I receive a take down notice – Here kiddies!




activation-key 0xb23bcf4a 0x1c713b4f 0x7d53bcbc 0xc4f8d09c 0x0e24c6b6




Here I apply the key – note that the first time takes FOREVER and a day! Don’t worry just let it do it’s thing.




ciscoasa>
ciscoasa> en
Password:
ciscoasa# conf t
ciscoasa(config)#
***************************** NOTICE *****************************
Help to improve the ASA platform by enabling anonymous reporting,
which allows Cisco to securely receive minimal error and health
information from the device. To learn more about this feature,
please visit: http://www.cisco.com/go/smartcall
Would you like to enable anonymous error reporting to help improve
the product? [Y]es, [N]o, [A]sk later: n
In the future, if you would like to enable this feature,
issue the command "call-home reporting anonymous".
Please remember to save your configuration.
ciscoasa(config)# activation-key 0xb23bcf4a 0x1c713b4f 0x7d53bcbc 0xc4f8d09c 0$
Validating activation key. This may take a few minutes...
Failed to retrieve permanent activation key.




Now the important thing to note here is the following. Restarting the ASA. DO NOT RELOAD. You must not reload otherwise you will need to put in another key the next time you boot up. It takes 5 minutes so it can slow you down.


What I have found is that stopping/starting via right click in the GNS3 gui will help you here. It remembers its information.




copy running-config startup-config
copy startup-config disk0




This is what allows configurations consistent through a restart.




Licensed features for this platform:
Maximum Physical Interfaces : Unlimited perpetual
Maximum VLANs : 100 perpetual
Inside Hosts : Unlimited perpetual
Failover : Active/Active perpetual
VPN-DES : Enabled perpetual
VPN-3DES-AES : Enabled perpetual
Security Contexts : 5 perpetual
GTP/GPRS : Disabled perpetual
AnyConnect Premium Peers : 25 perpetual
AnyConnect Essentials : Disabled perpetual
Other VPN Peers : 5000 perpetual
Total VPN Peers : 0 perpetual
Shared License : Enabled perpetual
AnyConnect for Mobile : Disabled perpetual
AnyConnect for Cisco VPN Phone : Disabled perpetual
Advanced Endpoint Assessment : Enabled perpetual
UC Phone Proxy Sessions : 10 perpetual
Total UC Proxy Sessions : 10 perpetual
Botnet Traffic Filter : Enabled perpetual
Intercompany Media Engine : Enabled perpetual




Well. That is nice. VPNs, Failover, 3DES-AES, and contexts. Spoilt aren’t you!  That’s it for provisioning an ASA in qemu. IF there is any files you are missing a light google will help you find what you are missing – allegedly. It took me about 90 minutes of research and not much longer putting it together.


Next up we bind GNS3 to our host machine, kick the console for SSH access from the host then TFTP ASDM onto our device! Phwoar. CCNA CCNP CCIE SECURITY LABS FOR EVERYBODY!


Update –  Shout out to Routergods.net for the love. Check his ASA video out that aligns to this! http://www.youtube.com/watch?v=jAwPuw7G6u8&feature=g-all-u


GNS3-and-Cisco-ASA-8-4-part-2