Archive for October, 2013

OUTSIDE_IN -> |outside Interface |

|outside Interface| -> OUTSIDE_OUT

!– allow traceroute return packets 
!– allow traceroute return packets 
!– allow pings across firewall
!– allow pings across firewall

access-list OUTSIDE_IN extended permit icmp any any unreachable
access-list OUTSIDE_IN extended permit icmp any any time-exceeded
access-list OUTSIDE_IN extended permit icmp any any echo 
access-list OUTSIDE_IN extended permit icmp any any echo-reply

! Egress ACL: permit ping packets
access-list OUTSIDE_OUT extended permit icmp any any echo
access-list OUTSIDE_OUT extended permit icmp any any echo-reply

 !–to allow ASA to ping to any destination but not to respond to ping:
icmp permit any echo-reply outside

!– allow ASA to perform traceroute and to accept pMTU messages
# icmp permit any time-exceeded outside
# icmp permit any unreachable outside

#debug icmp trace

ICMP echo request from inside:150.1.2.2 to outside:136.1.123.12 ID=16 seq=0 len=72
ICMP echo request translating inside:150.1.2.2 to outside:136.1.123.33
ICMP echo request from inside:150.1.2.2 to outside:136.1.123.12 ID=16 seq=1 len=72
ICMP echo request translating inside:150.1.2.2 to outside:136.1.123.33
ASA3# sh xlate
1 in use, 2 most used
Flags: D – DNS, e – extended, I – identity, i – dynamic, r – portmap,
s – static, T – twice, N – net-to-net
ICMP PAT from any:150.1.2.2/16 to any:136.1.123.33/16 flags ri idle 0:00:29 timeout 0:00:30

Example:
ACL No one can ping firewall but firewall can ping out on all interfaces.
Firewall responds to traceroute and pMTU discovery:

icmp permit any echo-reply outside
icmp permit any time-exceeded outside
icmp permit any unreachable outside

icmp permit any echo-reply inside
icmp permit any time-exceeded inside
icmp permit any unreachable inside

icmp permit any echo-reply dmz1
icmp permit any time-exceeded dmz1
icmp permit any unreachable dmz1

icmp permit any echo-reply dmz2
icmp permit any time-exceeded dmz2
icmp permit any unreachable dmz2

##### A bit of theory #####

The traceroute command is used to discover the routes that packets actually take when traveling to their destination. The device sends out a sequence of User Datagram Protocol (UDP) datagrams to an invalid port address at the remote host.
Three datagrams are sent, each with a Time-To-Live (TTL) field value set to one. The TTL value of 1 causes the datagram to “timeout” as soon as it hits the first router in the path; this router then responds with an ICMP Time Exceeded Message (TEM) indicating that the datagram has expired.
Another three UDP messages are now sent, each with the TTL value set to 2, which causes the second router to return ICMP TEMs. This process continues until the packets actually reach the other destination.

Since these datagrams are trying to access an invalid port at the destination host, ICMP Port Unreachable Messages are returned, indicating an unreachable port; this event signals the Traceroute program that it is finished.

The purpose behind this is to record the source of each ICMP Time Exceeded Message to provide a trace of the path the packet took to reach the destination

For IPv4 packets, Path MTU Discovery works by setting the Don’t Fragment (DF) option bit in the IP headers of outgoing packets. Then, any device along the path whose MTU is smaller than the packet will drop it, and send back an Internet Control Message Protocol (ICMP) Fragmentation Needed (Type 3, Code 4) message containing its MTU, allowing the source host to reduce its Path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation.

IPv6 routers do not support fragmentation or the Don’t Fragment option. For IPv6, Path MTU Discovery works by initially assuming the path MTU is the same as the MTU on the link layer interface through which the traffic is being sent. Then, similar to IPv4, any device along the path whose MTU is smaller than the packet will drop the packet and send back an ICMPv6 Packet Too Big (Type 2) message containing its MTU, allowing the source host to reduce its Path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation.

The ping command uses a series of Internet Control Message Protocol (ICMP) Echo messages to determine:
– Whether a remote host is active or inactive.
– The round-trip delay in communicating with the host.
– Packet loss.

The ping command first sends an echo request packet to an address, then waits for a reply. The ping is
successful only if:
– the echo request gets to the destination, and
– the destination is able to get an echo reply back to the source within a predetermined time called a
timeout. The default value of this timeout is two seconds on Cisco routers.

The TTL value of a ping packet cannot be changed.

################################################################

ASA primary unit failover commands:

!– enables failover interface

ASA1(config)#inte et0/3    

ASA1(config-if)# no shut

ASA1(config)# int e0/0
ASA1(config-if)# nameif outside
ASA1(config-if)# ip address 160.10.0.13 255.255.255.0 standby 160.10.0.14
ASA1(config-if)# no shut

ASA1(config-if)# int e0/1
ASA1(config-if)# nameif inside
ASA1(config-if)# ip address 10.0.0.13 255.255.255.0 standby 10.0.0.14
ASA1(config-if)# no shut

!-Enables rip routing protocol
ASA1(config)# router rip      
ASA1(config-router)# ver 2
ASA1(config-router)# network 10.0.0.0
ASA1(config-router)# network 160.10.0.0
ASA1(config-router)# no auto-summary

!- Default NAT to permit inside to outside traffic
ASA1(config)# object net ANY-INSIDE
ASA1(config-network-object)# subnet 0 0
ASA1(config-network-object)# nat (inside,outside) dynamic interface
ASA1(config-network-object)# exit

!- Permits icmp for testing

ASA1(config)# access-list OUT-IN permit icmp any any echo-reply        
ASA1(config)# access-group OUT-IN in interface outside

!– Failover commands

ASA1(config)# failover lan unit primary
ASA1(config)# failover lan interface FAILOVER-INT et0/3
ASA1(config)# failover  link FAILOVER-INT e0/3
ASA1(config)# failover interface ip FAILOVER-INT 1.1.1.13 255.255.255.0 standby 1.1.1.14
ASA1(config)# failover

ASA1(config)# monitor-interface outside
ASA1(config)# monitor-interface inside

ASA1(config)# failover polltime unit msec 200 holdtime msec 800
ASA1(config)# failover polltime interface msec 500 holdtime 5
ASA1(config)# failover interface-policy 1

Secondary unit failover commands:

ASA2(config)# int e0/3
ASA2(config-if)# no shut
ASA2(config-if)# exit

ASA2(config)# failover lan unit secondary
ASA2(config)# failover lan interface FAILOVER-INT e0/3
ASA2(config)# failover link FAILOVER-INT e0/3

ASA2(config)# failover interface ip FAILOVER-INT 1.1.1.13 255.255.255.0 standby 1.1.1.14
ASA2(config)# failover

************WARNING****WARNING****WARNING********************************
Mate version 8.4(5) is not identical with ours 8.4(6)
************WARNING****WARNING****WARNING********************************

ASA1# sh failover state

State          Last Failure Reason      Date/Time
This host  –   Primary
Active         None
Other host –   Secondary
Standby Ready  Comm Failure             14:33:36 UTC Sep 6 2013

This shows that failover link commands was not entered. Once command is entered like this:

ASA1(config)# failover link FAILOVER-INT et0/3

 

When everything looks good:

ASA1# sh failover
Failover On
Failover unit Primary
Failover LAN Interface: FAILOVER-INT Ethernet0/3 (up)
Unit Poll frequency 200 milliseconds, holdtime 800 milliseconds
Interface Poll frequency 500 milliseconds, holdtime 5 seconds
Interface Policy 1
Monitored Interfaces 2 of 110 maximum
Version: Ours 8.4(5), Mate 8.4(6)
Last Failover at: 14:33:20 UTC Sep 6 2013
This host: Primary – Active
Active time: 1005 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.4(5)) status (Up Sys)
Interface outside (160.10.0.13): Normal (Monitored)
Interface inside (10.0.0.13): Normal (Monitored)
slot 1: empty
Other host: Secondary – Standby Ready
Active time: 0 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.4(6)) status (Up Sys)
Interface outside (160.10.0.14): Normal (Monitored)
Interface inside (10.0.0.14): Normal (Monitored)
slot 1: empty

Stateful Failover Logical Update Statistics
Link : FAILOVER-INT Ethernet0/3 (up)
Stateful Obj    xmit       xerr       rcv        rerr
General         11         0          10         0
sys cmd         10         0          10         0
up time         0          0          0          0
RPC services    0          0          0          0
TCP conn        0          0          0          0
UDP conn        0          0          0          0
ARP tbl         0          0          0          0
Xlate_Timeout   0          0          0          0
IPv6 ND tbl     0          0          0          0
VPN IKEv1 SA    0          0          0          0
VPN IKEv1 P2    0          0          0          0
VPN IKEv2 SA    0          0          0          0
VPN IKEv2 P2    0          0          0          0
VPN CTCP upd    0          0          0          0
VPN SDI upd     0          0          0          0
VPN DHCP upd    0          0          0          0
SIP Session     0          0          0          0
Route Session   0          0          0          0
User-Identity   1          0          0          0

Logical Update Queue Information
Cur     Max     Total
Recv Q:         0       2       10
Xmit Q:         0       25      108

ASA1#
************WARNING****WARNING****WARNING********************************
Mate version 8.4(6) is not identical with ours 8.4(5)
************WARNING****WARNING****WARNING*****************************

!– You can run commands on standby unit by issuing:

ASA1# failover exec standby show run router rip
router rip
network 136.1.0.0
version 2
no auto-summary

!– once you establish connection thru ASA, check connections on primary and standby. This show that statefull tracking is happening.

ASA1# sh conn
11 in use, 13 most used
TCP outside 160.10.0.2:23 inside 10.0.0.1:38081, idle 0:00:01, bytes 67, flags UIO
ASA1#

ASA1# failover exec standby show conn
11 in use, 13 most used
TCP outside 160.10.0.2:23 inside 10.0.0.1:38081, idle 0:01:07, bytes 67, flags UIO
ASA1#

!– When you shut down switch interface where primary outside interface is connected to, the switchover happens:

ASA1(config)#
Switching to Standby

!– Check failover status on secondary unit:

ASA1# sh failover 
Failover On
Failover unit Secondary
Failover LAN Interface: FAILOVER Ethernet0/3 (up)
Unit Poll frequency 200 milliseconds, holdtime 800 milliseconds
Interface Poll frequency 500 milliseconds, holdtime 5 seconds
Interface Policy 1
Monitored Interfaces 2 of 110 maximum
Version: Ours 8.4(3), Mate 8.4(5)
Last Failover at: 16:10:44 UTC Sep 9 2013
This host: Secondary – Active
Active time: 117 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.4(3)) status (Up Sys)
Interface outside (160.10.0.13): Normal (Waiting)
Interface inside (10.0.0.13): Normal (Monitored)
slot 1: empty
Other host: Primary – Failed
Active time: 844 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.4(5)) status (Up Sys)
 Interface outside (160.10.0.14): No Link (Waiting)
Interface inside (10.0.0.14): Normal (Monitored)
slot 1: empty

Stateful Failover Logical Update Statistics
Link : FAILOVER Ethernet0/3 (up)
Stateful Obj    xmit       xerr       rcv        rerr
General         76         0          82         0
sys cmd         75         0          75         0
up time         0          0          0          0
RPC services    0          0          0          0
TCP conn        1          0          4          0
UDP conn        0          0          0          0
ARP tbl         0          0          2          0
Xlate_Timeout   0          0          0          0
IPv6 ND tbl     0          0          0          0
VPN IKEv1 SA    0          0          0          0
VPN IKEv1 P2    0          0          0          0
VPN IKEv2 SA    0          0          0          0
VPN IKEv2 P2    0          0          0          0
VPN CTCP upd    0          0          0          0
VPN SDI upd     0          0          0          0
VPN DHCP upd    0          0          0          0
SIP Session     0          0          0          0
Route Session   0          0          0          0
User-Identity   0          0          1          0

Logical Update Queue Information
Cur     Max     Total
Recv Q:         0       5       648
Xmit Q:         0       1       188
ASA1#

##### A bit of theory #####

In failover, one firewall unit is designated as primary and the other as secondary. Initially, the primary unit is active and the secondary is standby. Only one unit is active and forwards traffic at any given time, while the other remains in standby mode. When the active unit fails, the standby assumes the role of the active unit by taking its IP/MAC addresses. The unit still remains known as the “secondary” unit, but it operates in an “active” mode. Failover is available in both transparent firewall and routed firewall modes.

The firewall supports two types of failover: stateful and regular. During the regular failover process, the states of the currently active sessions, which include NAT translations, etc., are not copied between the active and standby units. After a failover, users must re-initiate their connections. Stateful failover preserves all connection states during a failover, making the switchover process nearly seamless from the end user perspective. The configurations of both units are kept synchronized at all times, because the commands from the active unit are always replicated to the standby

Failover occur under three general conditions:

1. The active unit detects system health issues (software, hardware or power failure).

In this case the active unit become a standby and secondary become primary unit immediately.

2. The standby unit detects loss of contact with the active unit across the failover interface.

Both units constantly send keepalive message to each other across the failover link. If the standby unit loses 3 consecutive keepalives, it will try to restore contact with the active unit. The standby unit will broadcast ARP requests out of all interfaces, asking for the IP address of the active unit. If it receives the ARP response on the failover link, nothing changes. If the response is only received on the non-failover link, the standby unit marks the failover link as non-functional but does not fail over. Manual intervention is required to fix the problem. If no response is received on any interface, the standby unit fails over.

3. The active unit detects loss of the monitored interfaces above the configured threshold.

By default, when interface monitoring is enabled, every single physical interface failure would force the active unit to give its role to the standby. In the most simple case, if the unit detects loss of carrier on the interface, it immediately declares the interface to be down. To account for more complex cases, interface monitoring is performed by sending and receiving keepliave packets to the standby unit. If the active unity does not receive any hello packets for the duration of half of the hold-interval, it will attempt to count packets on the monitored interface to see if any traffic enters the interface. If this does not succeed, the unit will attempt to send ARP requests for known destinations to provoke some responses and see if this generates traffic. If all attempts to generate a receive traffic fails, the unit will initiate failover.

By default, the firewall monitors all physical interfaces with IP addresses assigned. At the same time, sub-interfaces are not monitored by default. With default settings, any interface failure will trigger failover.

################################################################

Configure the internal interface vlan

ASA1 (config)# interface Vlan 1
ASA1(config-if)# nameif inside
ASA1(config-if)# security-level 100
ASA1(config-if)# ip address 192.168.1.1 255.255.255.0
ASA1(config-if)# no shut

Configure the external interface vlan (connected to Internet)
ASA1 (config)# interface Vlan 2
ASA1(config-if)# nameif outside
ASA1(config-if)# security-level 0
ASA1(config-if)# ip address 200.200.200.1 255.255.255.0
ASA1(config-if)# no shut

Assign Ethernet 0/0 to Vlan 2
ASA1 (config)# interface Ethernet0/0
ASA1(config-if)# switchport access vlan 2
ASA1(config-if)# no shut

Enable the rest interfaces with no shut
ASA1 (config)# interface Ethernet0/1
ASA1(config-if)# no shut

Do the same for Ethernet0/1 to 0/7.

Configure PAT on the outside interface
ASA1 (config)# global (outside) 1 interface
ASA1 (config)# nat (inside) 1 0.0.0.0 0.0.0.0
ASA1 (config)#object network obj_any
ASA1 (config)#subnet 0.0.0.0 0.0.0.0
ASA1 (config)#nat (inside, outside) dynamic interface

Configure default route towards the ISP (assume default gateway is 200.200.200.2)
ASA1 (config)# route outside 0.0.0.0 0.0.0.0 200.200.200.2 1

The above steps are the absolutely necessary steps you need to configure for making the appliance operational. The next steps would include Access Control Lists, Static NAT, DHCP, DMZ zones, authentication etc.

################################################################

Configure RIPv2 on routers using clear-text and MD5 hash for authC

Simple diagram:
R1-> rip clear-text <-R3-> rip MD5 <-R2

Router1:

Router1(config)#key chain TEXT                                                   !– key chain name
Router1(config-keychain)#key 1                                                   !– key identifier
Router1(config-keychain-key)#key-string CLEARTEXT          !– key chain string

Router1(config)#router rip
Router1(config-router)#ver 2
Router1(config-router)#network 140.1.0.0                             !–RIP advertized networks
Router1(config-router)#network 160.1.0.0
Router1(config-router)#no auto-summary

Router1(config)#int f0/0
Router1(config-if)#ip rip authentication mode text                 !–clear-text authc mode
Router1(config-if)#ip rip authentication key-chain TEXT       !–key-chain name used for authc

Router2:
Router2(config)#router rip
Router2(config-router)#version 2
Router2(config-router)#network 140.1.0.0
Router2(config-router)#network 160.1.0.0
Router2(config-router)#no auto-summary
Router2(config-router)#exit

Router2(config)#key chain MD5
Router2(config-keychain)#key 1
Router2(config-keychain-key)#key-string MD5HASH

Router2(config-keychain-key)#int f0/0
Router2(config-if)#ip rip authentication mode md5
Router2(config-if)#ip rip authentication key-chain MD5

Router 3:
Router3(config)#key chain TEXT
Router3(config-keychain)#key 1
Router3(config-keychain-key)#key-string CLEARTEXT

Router3(config)#key chain MD5
Router3(config-keychain)#key 1
Router3(config-keychain-key)#key-string MD5HASH

Router3(config)#route rip
Router3(config-router)#version 2
Router3(config-router)#network 140.1.0.0
Router3(config-router)#network 160.1.0.0
Router3(config-router)#no auto-summary

Router3(config)#int f0/1
Router3(config-if)#ip rip authentication mode text
Router3(config-if)#ip rip authentication key-chain TEXT

Router3(config-if)#int f0/0
Router3(config-if)#ip rip authentication mode md5
Router3(config-if)#ip rip authentication key-chain MD5

Verify:
Router3#sh ip route rip
160.1.0.0/32 is subnetted, 2 subnets
R       160.1.1.1 [120/1] via 140.1.13.1, 00:00:27, FastEthernet0/1

Router1#
Router1#sh ip route rip

140.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
R        140.1.23.0/24 [120/1] via 140.1.13.3, 00:00:15, FastEthernet0/0
160.1.0.0/32 is subnetted, 2 subnets
R        160.1.3.3 [120/1] via 140.1.13.3, 00:00:15, FastEthernet0/0
Router1#

Router3#debug ip rip

RIP: received packet with text authentication CLEARTEXT
RIP: received v2 update from 140.1.13.1 on FastEthernet0/1
160.1.1.1/32 via 0.0.0.0 in 1 hops
RIP: sending v2 update to 224.0.0.9 via Loopback0 (160.1.3.3)
RIP: build update entries
140.1.13.0/24 via 0.0.0.0, metric 1, tag 0
140.1.23.0/24 via 0.0.0.0, metric 1, tag 0
160.1.1.1/32 via 0.0.0.0, metric 2, tag 0
RIP: ignored v2 packet from 160.1.3.3 (sourced from one of our addresses)
RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (140.1.

Wrong authentication shows this error outputs:

Router2#
RIP: ignored v2 packet from 136.1.23.3 (invalid authentication)
RIP: sending v2 update to 224.0.0.9 via Loopback0 (150.1.2.2)
RIP: build update entries
136.1.23.0/24 via 0.0.0.0, metric 1, tag 0
RIP: ignored v2 packet from 150.1.2.2 (sourced from one of our addresses)
RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (136.1.23.2)
RIP: build update entries
150.1.2.2/32 via 0.0.0.0, metric 1, tag 0
RIP: ignored v2 packet from 136.1.23.3 (invalid authentication)
RIP: sending v2 update to 224.0.0.9 via Loopback0 (150.1.2.2)
RIP: build update entries
136.1.23.0/24 via 0.0.0.0, metric 1, tag 0

##### Theory #####
RIP authentication is configured in three steps:

1. define a global key chain
2. enable authentication mode (clear-text or MD5) on the RIP interfaces
3. apply the key chain to the interface
Note that for MD5 based authentication, the key number in the key chain must match between the neighbors.

Verification – check if the routes from the RIP neighbor are installed in the routing table, authentication was successful.

################################################################