IOS in-flight upgrade on ASA failover pair

IOS in-flight upgrade on ASA failover pair

1. Copy new OS to flash on both primary and secondary
2. Force primary to be active and reload the standby/secondary
3. After back up, force standby/secondary to active status
4. Reload primary which is currently in standby status
5. After back up, restore active status to desired unit (s)

Transparent Firewall - ASA

Transparent Firewall

Act like a layer 2 switch without IP but still can do filtering, nat, etc. ARP is allowed by default.
But cannot have VPN. ASA is managed via console or BVI
All configs are gone when firewall mode is changed
Transparent ASA doesn't forward bradcast/multicast(routing protocols, DHCP clients, BPDU,etc) by default.

A transparent firewall does not participate in IP routing.The only IP configuration required for ASA is to set the BVI address which is required because the ASA uses this address as the source address for traffic originating on the ASA such as system messages or communications with AAA servers.You can also use this address for remote management access.This address must be on the same subnet as the upstream and downstream routers.

ASA(config)#interface bvi 1
ASA(config-if)#ip address 10.1.1.5 255.255.255.0

Active-Active Failover

IP addresses of failover link and stateful link will never change regardless of what failover state the firewall is in. By default, the ASA who is active unit for group 1 is also active for system configuration as well..

Configuration

1. Starting on the unit that will be the PRIMARY,with multiple mode and context already in place,configure it in the system context. Failover gorup 1 is the default failover group. Create the first of the two failover groups
   ASA1(config)#failover group 1
2. Tell the failover system that the PRIMARY unit should be active for any context in this "failover group #1"
   primary
3. Optionally, tell the system to take over the active role 2 minutes after a reboot by the primary unit for this group
   preempt 120
4. Do the same for failover group 2
   failover group 2
5. Tell the failover system that the "SECONDARY" unit should be active for any context in this "failover group #2"
   secondary
6. Request a preempt 2 minutes after reboot if by the secondary unit for this group
   preempt 120
7. Tell the system that each of the contexts are assigned to 1 of the 2 failover groups
   ASA1(config)#context Ctx-1
   ASA1(config-ctx)#join-failover-gorup 1
   ASA1(config-ctx)#exitASA1(config)#context Ctx-2
   ASA1(config-ctx)#join-failover-group 2

1. Prepare the failover interfaces (the lan fail and stateful link). Go to the these interfaces and unshut the ports.
   no shutdown
2. Tell this physical box its "priority" or title (Primary or Secondary).This priority(name) never changes for this physical unit on ASA1
   failover lan unit primary
3. Configure the names and IP addresses for the 2 failover connections on ASA1
   failover lan interface fail-config G4
   failover link fail-state G5
   failover interface ip fail-config 1.1.1.1 255.255.255.252 standby 1.1.1.2
   failover interface ip fail-state 2.2.2.1 255.255.255.252 standby 2.2.2.2
4. Set the prompt to include which context(if any) we are working in.
   prompt hostname context
5. Change from the sytem execution space to the context of Ctx-1 in order to add the standby addresses
   changeto context Ctx-1
   int G1
   ip address 10.0.0.1 255.255.255.0 standby 10.0.0.2
   int G3
   mac-address cc1e.6783.1111 standby cc1e.6783.2222 //optionally add MAC addresses on the shared interface for this context
   ip address 192.168.1.171 255.255.255.0 standby 192.168.1.181

1. Change from Ctx-1 and move to the context of Ctx-2 in order to add standby addresses
   changeto context Ctx-2
   interface ctx2_inside
   ip address 10.2.2.1 255.255.255.0 standby 10.2.2.2
   interface ctx2_outside
   mac-address cc1e.6783.3333 standby cc1e.6783.4444
   ip address 192.168.1.172 255.255.255.0 standby 192.168.1.182
2. Move back to teh sytem execution space and turn on failover
   changeto system
   failover

1. Save the system config and all the contexts individual configs at the same time
   write mem all
   show failover state
2. Go to secondary firewall, verify it is in multiple mode which is required for active/active. check same hardware, same number of interface, model,same function, etc.
   show mode
3. Tell this ASA what priority(title) it will have.Primary or Secondary
   failover lan unit secondary
4. Makesure failver interface is up.Define failover interface name and IPs
   failover lan interface fail-config G4
   failover interface ip fail-config 1.1.1.1 255.255.255.252 standby 1.1.1.2
5. Tun on failover
   failover

prompt hostname priority context state

To rectify Asymmetric routing if there is any, use ASR group. Add the interface to ASR group(under routing) in each context. Maximum of 2 failover groups can be created.

Configuring Support for Asymmetrically Routed Packets

When running in Active/Active failover, a unit may receive a return packet for a connection that originated through its peer unit. Because the ASA that receives the packet does not have any connection information for the packet, the packet is dropped. This most commonly occurs when the two ASAs in an Active/Active failover pair are connected to different service providers and the outbound connection does not use a NAT address.

You can prevent the return packets from being dropped using the asr-group command on interfaces where this is likely to occur. When an interface configured with the asr-group command receives a packet for which it has no session information, it checks the session information for the other interfaces that are in the same group. If it does not find a match, the packet is dropped. If it finds a match, then one of the following actions occurs:

•If the incoming traffic originated on a peer unit, some or all of the layer 2 header is rewritten and the packet is redirected to the other unit. This redirection continues as long as the session is active.

•If the incoming traffic originated on a different interface on the same unit, some or all of the layer 2 header is rewritten and the packet is reinjected into the stream.

-----

How the Security Appliance Classifies Packets

Each packet that enters the ASA must be classified, so that the ASA can determine to which context to send a packet. This section includes the following topics:

•Valid Classifier Criteria

•Invalid Classifier Criteria

•Classification Examples

Valid Classifier Criteria

This section describes the criteria used by the classifier, and includes the following topics:

•Unique Interfaces

•Unique MAC Addresses

•NAT Configuration

Unique Interfaces

If only one context is associated with the ingress interface, the ASA classifies the packet into that context. In transparent firewall mode, unique interfaces for contexts are required, so this method is used to classify packets at all times.

Unique MAC Addresses

If multiple contexts share an interface, then the classifier uses the interface MAC address. The ASA lets you assign a different MAC address in each context to the same shared interface, whether it is a shared physical interface or a shared subinterface. By default, shared interfaces do not have unique MAC addresses; the interface uses the physical interface burned-in MAC address in every context. An upstream router cannot route directly to a context without unique MAC addresses. You can set the MAC addresses manually when you configure each interface (see the "Configuring the MAC Address" section), or you can automatically generate MAC addresses (see the "Automatically Assigning MAC Addresses to Context Interfaces" section).

NAT Configuration

If you do not have unique MAC addresses, then the classifier intercepts the packet and performs a destination IP address lookup. All other fields are ignored; only the destination IP address is used. To use the destination address for classification, the classifier must have knowledge about the subnets located behind each security context. The classifier relies on the NAT configuration to determine the subnets in each context. The classifier matches the destination IP address to either a static command or a global command. In the case of the global command, the classifier does not need a matching natcommand or an active NAT session to classify the packet. Whether the packet can communicate with the destination IP address after classification depends on how you configure NAT and NAT control.

For example, the classifier gains knowledge about subnets 10.10.10.0, 10.20.10.0 and 10.30.10.0 when the context administrators configure staticcommands in each context:

•Context A:

static (inside,shared) 10.10.10.0 10.10.10.0 netmask 255.255.255.0

•Context B:

static (inside,shared) 10.20.10.0 10.20.10.0 netmask 255.255.255.0

•Context C:

static (inside,shared) 10.30.10.0 10.30.10.0 netmask 255.255.255.0

Virtual firewalls - Multiple Context Mode

Virtual firewalls - Multiple Context Mode

Multiple context mode does not support dynamic routing protocols, VPN.

Steps

1. Covert system to multiple mode
2. Copies previous running-config is saved to flash as "old_running.cfg"
3. A new context named as "admin" is created with the running config. Transparent to users and traffic flow as before.
4. Then, create additional context

Each context has

• name of Context
• Allocation of resources
• Config URL

Commands to check
show mode
show context
show firewall

Configuration
mode multiple
Need to reboot firewall.

Use changeto context command to switch to the context. (use prompt hostname context)
ASA1# changeto context admin
ASA1/admin#
ASA1/admin# changeto context system or changeto system
ASA1#

Adding/deleting of a new context can be done in admin context (with admin role). We can assign a context admin role with the command - admin-context <context-name>

Remember to unshut the ports in admin context for other normal contexts.

Active/Standby failover

Active/Standby failover
Failover(LAN failover) cable and Stateful cable
In stateful replication - DHCP leased addresses, phone proxy info, hardware modules are not replicated.
HTTP is replicated if HTTP option is enabled.
Active unit uses the "system" IP addresses while Standby unit uses "standby" addresses (in current IP address).

If failover happens, normal routed interfaces on the new active unit will use the system IP address. The IP addresses on the configuration and stateful failover links do not change or swap.
Only implement config changes on an active unit.

When failover happens, active firewall interface takes over the mac addresses of previously active firewall interfaces.

Failover Configuration
When a failover pair starts, (almost) entire configuration from the active unit is replicated to the standby which overwrites the standby's old configuration. Use cross over cables for failover and stateful links.If you use a Vlan for the failover cables, enalbe portfast to minimize failover delay.

1. Go to each interface and assign active and standby address. Interface IPs on primary and secondary must be in same vlan.
   ip address 10.0.0.1 255.255.255.252 standby 10.0.0.2
2. Tell ASA that gig3 will be named "fail-1" and that will be used to replicate the configuration between ASA1 and ASA2
   failover lan interface fail-1 G3
3. Use the failover command to assign "fail-1" the active and standby IP addresses
   failover interface ip fail-1 10.1.1.1 255.255.255.252 standby 10.1.1.2
4. Specify the key to be used between primary and secondary
   failver key cisco
5. Tell the ASA that gig4 will be named "fail-2" .Note that the word "link" is the clue to identify this is the stateful connection. This is for the link used just for "stateful" info to be shared between active and standby
   failover link fail-2 G4
6. Assign IP address for "fail-2" active and standby
   failover interface ip fail-2 10.2.2.1 255.255.255.252 standby 
7. Tell this ASA that its title will be "Primary". If an active is found to already be on the network (after power trip or something), standby will get a full "re-sync" of the config from that current active device.
   failover lan unit primary
8. Default hostname will be the same for both active and standby units due to the config being replicated. So, change the prompt to show: Primary or Secondary and Active or Standby
   prompt hostname priority state
   
9. Turn on the failover
   failover
      ---  Optionally, also replicate the HTTP sessions
            failover replication http
10. On secondary unit, just need to configure failover interface
    clear config all
    int G3
    no shut
    failover lan interface fail-1 G3
    failover interface ip fail-1 10.1.1.1 255.255.255.252 standby 10.1.1.2
    failover key cisco
    failover lan unit secondary
    failover

--------------------------

• To troubleshoot failover
  failover
• To force failover to standby device, issue below command on active unit
  no failover active

Reverse Path forwarding (ip verify reverse-path interface)

Reverse Path forwarding (ip verify reverse-path interface)

Unicast RPF guards against IP spoofing (a packet uses an incorrect source IP address to obscure its true source) by ensuring that all packets have a source IP address that matches the correct source interface according to the routing table.

Normally, the ASA only looks at the destination address when determining where to forward the packet. Unicast RPF instructs the ASA to also look at the source address; this is why it is called Reverse Path Forwarding. For any traffic that you want to allow through the ASA, the ASA routing table must include a route back to the source address. See RFC 2267 for more information.

For outside traffic, for example, the ASA can use the default route to satisfy Unicast RPF protection. If traffic enters from an outside interface, and the source address is not known to the routing table, the ASA uses the default route to correctly identify the outside interface as the source interface.

If traffic enters the outside interface from an address that is known to the routing table, but is associated with the inside interface, then the ASA drops the packet. Similarly, if traffic enters the inside interface from an unknown source address, the ASA drops the packet because the matching route (the default route) indicates the outside interface.

Unicast RPF is implemented as follows:

• ICMP packets have no session, so each packet is checked.
• UDP and TCP have sessions, so the initial packet requires a reverse route lookup. Subsequent packets arriving during the session are checked using an existing state maintained as part of the session. Non-initial packets are checked to ensure that they arrived on the same interface used by the initial packet.

Examples

The following example enables Unicast RPF on the outside interface:

ciscoasa(config)# ip verify reverse-path interface outside

Related Commands

Command	Description
clear configure ip verify reverse-path	Clears the configuration set using the ip verify reverse-path command.
clear ip verify statistics	Clears the Unicast RPF statistics.
show ip verify statistics	Shows the Unicast RPF statistics.
show running-config ip verify reverse-path	Shows the configuration set using the ip verify reverse-path command.

BGP Theory and Concepts; BGP Attributes

Administrative distance - EBGP = 20, IBGP = 200

BGP neighbor relationships
Neighbors are manually configured.
Neighbors start in IDLE state
 -1st stage: Active
 -2nd stage: Open sent
 -3rd stage: Open Confirmed
 -4th stage: Established

Hello message sent once every 60 seconds with a holddown of 180 seconds
Neighbors are capable of MD5 authentication

Rule of Synchronization
Routes learned via BGP must be validated by the interior routing table before they can be advertised to remote peers.

If Synchronization is turned on at R1, it receives eBGP routes from AS4300 and AS2300 but R1 does not install them in routing table.

After Synchronization is turned off at R1, it installs eBGP routes in its routing table. It does not advertise to its iBGP peer due to Rule of Split-Horizon.

Rule of Split-Horizon (Per BGP)
Routes learned via IBGP will never be sent to another IBGP peer. It's to prevent loop and Split-horizon is good if all IBGP are fully mesh.
To overrule this rule, configure route reflector. Of course iBGP peer (R4) must know how to reach 10.12.1.2 and 10.13.1.2 via IGP or static routes.

------------

BGP Attributes

Well-known mandatory Attributes

AS-Path

Next-Hop; next-hop on shared media (if receiving router is on the same subnet, next-hop remains the same)

Origin - Tells how the route originated(IGP(I),EGP(E),Unknow(redistribution)).


Well-known optional Attributes

Local Preference - gives you control over preferred routes,higher is better.

Weight - cisco proprietary, gives you control of routes on the SAME router. It does not affect routing policy of other routers in the AS

Atomic aggregate - Informs router that a route has been summarized.

Multi-exit discriminator(MED) - used to suggest an entry point into your AS. Lower is better.

Aggregator - Designates the IP address of the router who performed summarization.

Community - Used for route tagging.

ISIS

IS-IS

Link-state routing protocol
Uses Partical Route Calculation (PRC) for IP routes
Uses the DEFAULT metric on cisco routers (0-63)
Does not have a BACKBONE Area.Rather, a Backbone LEVEL
Requires a Single OSI ADDRESS

OSI Addressing
Hexadecimal
Composed of three parts
 -Area ID(Variable length)
 -Sytem ID(6 Bytes) --like a host address
 -NSEL(1 Byte) --like a service port
Read address from right to left because of Area ID(variable length)
49.003.1111.2222.3333.00
49.0152.3135.1AB2.FE00.63C9.00
49.005.1111.1111.1111.00
49 is a private address.

IS-IS routing maintains 2 IP Databases. 
  Level 1 Database: contains intra-area routes
  Level 2 Database: contains backbone routes
Routers may be L1, L2 or L1/L2.

Configuration
-trun on the routing process
-assign an OSI/NET address
-ip router isis -in each interface you want to run isis

OSPF

Administrative distance - 110

Technial overview of OSPF
1. OSPF send HELLO packet to multicast address 224.0.0.5 (all OSPF routers)
2. Neighbor evaluates packet. May or may not form neighbor
3. Link-state data exchange (DBD)
4. Net info. Recorded and Flooded.
5. When database complete, SPF Algorigthm runs.
6. Valid routes enter the routing table

OSPF Hello Packet
contains the followings
1. Router ID
2. Area ID (x)
3. Address of originate terface
4. Authentication information (x)
5. Hello Interval (x)
6. Dead Interval (x)
7. Priority
8. DR/BDR IDs
9. Neighbor Router IDs
 (x) = must match

OSPF Network Types
- Point to Point
There is no DR/BDR selection. Updates sent to 224.0.0.5.
- Broadcast
DR/BDR selection. They listen to 224.0.0.6
- NBMA network
Frame relay, ATM, Virtual circuti, Hub & spoke,
All neighbors are statically defined and unicast is used to communicate instead of multicast. DR selection-DR must have full connectivity to all neighbors.
- Point to multipoint
Very similar to NBMA but there is no DR election and messages will be multicasted.It treats its own virtual circuit as point to point(from HUB view)connection even though it's configured on multipoint interface.

http://www.youtube.com/watch?v=tSzJoxcep5o

----

Building OSPF neighbors and neighbor states

OSPF Areas, Router Types and LSAs

Reason to create normal area is for route summarization.
Unlike EIGRP, OSPF does not support route summarization anywhere in the network excpet at Area boundary routers(ABR) and Autonomous system boundary routers(ASBR).

STUB area blocks external route advertisements but still accept LSA type 3.
Totally stubby area blocks external route advertisements and ads from other areas.It only knows about routes in its area.

ABRs for Stub and Stubby areas inject default routes into these areas.
-----

LSA Type 1 - Router LSA. current networks that the router is connected to.
LSA Type 2 - DR advertising on behalf of a network. DR/BDR to other internal routers
LSA Type 3 - inter area routes injected by ABR. Routes from other areas
LSA Type 4 - Info about ASBR. Injected by ABR connected to other areas
LSA Type 5 - external LSA/routes injected by ASBR.
-------------
OSPF Link State database, Redistribution, Summarization

In stub area, default route is added automatically.

When redistributing Eigrp to ospf, must include 'subnets' command to redistribute classless subnets. If not, only classful networks are redistributed.
When redistributing to OSPF, E1 will add cost while E2 is a fixed cost in OSPF Areas.

To see OSPF link state database info -sh ip ospf database 

Summarization can be only done at/by ABR (hmm ASBR as well).
To summarize LSA Type 3 Area 1 route to inject to Area 0 at ABR - area 1 range 172.16.0.0 255.255.0.0
To summarize LSA Type 5 Area 1 route to inject to Area 0 at ASBR - summary-address 172.18.0.0 255.255.0.0

ASA inter interface and intra interface traffic

Higher security level interfaces can talk pass traffic to lower security interfaces by default but what if they are on the same security level? By default this is not permitted. Even if you define access-lists to permit the traffic, it is still denied.

Inter-interface traffic

Inter interface communication allows communications between different interfaces of the same security level.

ciscoasa(config)# same-security-traffic permit inter-interface

Intra-interface trafficIntra-interface permits flows of traffic that comes in on an interface and routed back out the same interface. This is denied by default. An example of this would be hair-pinning; Hub and Spoke VPN topologies utilize this methodology. 

ciscoasa(config)# same-security-traffic permit intra-interface

Redudant interface
active and standby interface. whichever interface comes first in config is activeinterface.

ACL, Routing, MPF, TCP advanced Options

ASA Access Control List

look at real IP address instead of global or mapped address
'Public Servers' option does NAT and access-list together
Normal mask in ACL; no wild card mask.

If there is global ACL, interace implicit deny is no longer effective. After interface ACL is checked and no match is found, traffic is checked against global ACL. If no match, then deny.
Choose 'Any' interface for Global ACL.

-------------

ASA Static route
The name of the interface we gonna use to reach that(advertised) network

-------------
clear config all -- clear running config
write erase -- clear startup config

Prioritization is always done outbound
Policing is inbound and outbound

Use TCP-map for TCP options
ASA performs ISN, Random sequence numbering
Use TCP-State Bypass option to ignore assymentric routing between source & destination
Use TCP Intercept for sync-flood attack. Set Half-formed session threshold limit, once it's above threshold, ASA intercept TCP Sync and respond on behalf of the server. If handshake is completed with the valid user, ASA send TCP 3 way handshake with the server.
ASA has a feature called TCP Sync cookies to handle DOS or Sync flood attack.

backtrack? for penetration testing

Layer 5-7 Advance application layer Inspection
policy-map type inspect ... match-all/match-any name

drop doesn't send a Reset packet. ASA does not allow any more packet for this session/connection.

NAT on Cisco ASA

TCP Ping on ASA can be used to test if the specified port is opened at destination IP
ping tcp x.x.x.x 22

For IOS 8.2 and older

Dynamic nat, pat, static nat, identity nat

nat (inside) 1 10.0.0.0 255.255.255.0 (creation of NAT group id 1 for 10./24 subnet coming in from inside)
global (outside) 1 192.168.1.51-192.168.1.100 (if group 1 traffic is going outside, map IP to )
global (outside) 1 192.168.1.101 (if group 1 traffic is going outside, map IP to 1.101; PAT )

static (dmz(real/incoming), outside(mapped/outgoing)) 192.168.1.175(mapped IP) 172.16.0.5(real IP)
static (dmz(real), inside(mapped)) 172.16.0.6(mapped IP) 172.16.0.6(original IP) – identity NAT

NAT 0 – do not translate if traffic matches the specified access list

Access-list NONAT permit ip (source net to dest net)
nat (inside) 0 access-list NONAT – 0 is reserved for NAT 0

-------------------------------------------------------------------------------------------------
http://www.tunnelsup.com/nat-for-cisco-asas-version-8-3/

NAT (IOS 8.3, 8.4 and newer)

The 3 sections of NAT

1.       Manual NAT

2.       Auto NAT

3.       Manual NAT (detailed)

If no NAT rule is hit for the traffic, traffic will be just forwarded as it is.

Auto/Object NAT (starts with object command)

Dynamic NAT
object network inside_10
   subnet 10.0.0.0 255.255.255.0
object network outside-pool
   range 192.168.1.51 192.168.1.100
object network inside_10
   nat dynamic outside-pool

Above config is for any 10.x address going through ASA (regardless of going to dmz, outside)

object network winxp-inside
 nat (inside,outside) static winxp-outside

object network inside_10

   nat (inside,any) dynamic outside-pool

Above config is for any 10.x address coming in from inside interface going through ASA (regardless of going to dmz, outside)
----------------------

Static NAT
nat (inside,outside) 1 source static <inside local> <inside global> destination static <outside local> <outside global>

Static NAT adds a rule for each direction (so total 2 NAT rules)
For static NAT, its xlate entry is always there in xlate table. So, can be used for server to be accessed by outside.

For dynamic NAT, tt only adds one rule.
---------------------

NOTES

http://www.tunnelsup.com/nat-for-cisco-asas-version-8-3/

The limitation that Auto NAT has is that it cannot take the destination into consideration when conducting it’s NAT. This also of course results in it not being able to alter the destination address either. To accomplish either of these tasks you must use “manual NAT”.

All of these terms are identical: Manual NAT, Twice NAT, Policy NAT, Reverse NAT. Don’t be confused by fancy mumbo jumbo.

http://www.cisco.com/c/en/us/td/docs/security/asa/asa83/asdm63/configuration_guide/config/nat_overview.html#wpxref64594

Main Differences Between Network Object NAT and Twice NAT

The main differences between these two NAT types are:

•How you define the real address.

–Network object NAT—You define NAT as a parameter for a network object; the network object definition itself provides the real address. This method lets you easily add NAT to network objects. The objects can also be used in other parts of your configuration, for example, for access rules or even in twice NAT rules.

–Twice NAT—You identify a network object or network object group for both the real and mapped addresses. In this case, NAT is not a parameter of the network object; the network object or group is a parameter of the NAT configuration. The ability to use a network object group for the real address means that twice NAT is more scalable.

•How source and destination NAT is implemented.

–Network object NAT— Each rule can apply to either the source or destination of a packet. So two rules might be used, one for the source IP address, and one for the destination IP address. These two rules cannot be tied together to enforce a specific translation for a source/destination combination.

–Twice NAT—A single rule translates both the source and destination. A matching packet only matches the one rule, and further rules are not checked. Even if you do not configure the optional destination address for twice NAT, a matching packet still only matches one twice NAT rule. The source and destination are tied together, so you can enforce different translations depending on the source/destination combination. For example, sourceA/destinationA can have a different translation than sourceA/destinationB.

•Order of NAT Rules.

–Network object NAT—Automatically ordered in the NAT table.

–Twice NAT—Manually ordered in the NAT table (before or after network object NAT rules).

See the "NAT Rule Order" section for more information.

We recommend using network object NAT unless you need the extra features that twice NAT provides. Network object NAT is easier to configure, and might be more reliable for applications such as Voice over IP (VoIP). (For VoIP, because twice NAT is applicable only between two objects, you might see a failure in the translation of indirect addresses that do not belong to either of the objects.)