Wednesday, 26 March 2014

Default Administrative Distance


This table shows default administrative distance value of routing protocols in use nowadays.


Thursday, 27 February 2014

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

Sunday, 23 February 2014

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

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

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.


Thursday, 20 February 2014

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.