Just a brief overview on setting up a IP SLA (icmp) on Cisco routers. The idea is to have a primary connectivity line (via MPLS) and backup connectivity line in case primary line is down. The backup line should take traffic load until primary line is back on line (such a fancy wordings).. The switch to the primary line should be automatically with no user interventions. If you need more info about IP SLA features you can click on the link.

Here is connectivity diagram:

ipsla

The idea is to have constant communication between RTR 4331 and RTR2′ loopback interface Lo1 (ip address 4.4.4.4). This simulates connectivity to, lets say Exchange server located in the main office, even dough these days most of the Exchange servers are in the cloud already but you got the point.

Lets get to the bread and butter:

Router’s configuration related to IP SLA only is listed below. Router has default config, no fancy stuff, IP addresses were assigned to interfaces as per diagram above.
ip sla 10
icmp-echo 4.4.4.4 source-interface GigabitEthernet0/0/0
frequency 5000
threshold 2
track 10 ip sla 10 reachability
ip sla schedule 10 life forever start-time now

ip route 0.0.0.0 0.0.0.0 10.238.254.134 track 10
ip route 0.0.0.0 0.0.0.0 1.1.1.2 10

 

Cool. Lets test this stuff..

FEI-R-4331-1#sh ip sla summary 
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending

ID           Type        Destination       Stats       Return      Last
(ms)        Code        Run
———————————————————————–
*10          icmp-echo   4.4.4.4           RTT=1       OK          5 minutes, 42
seconds ago

FEI-R-4331-1#traceroute 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 10.238.254.134 1 msec 1 msec 0 msec
2 20.20.20.22 0 msec *  1 msec

FEI-R-4331-1#

FEI-R-4331-1#sh ip sla statistics 
IPSLAs Latest Operation Statistics

IPSLA operation id: 10
Latest RTT: 1 milliseconds
Latest operation start time: 09:22:57 pdt Fri Mar 24 2017
Latest operation return code: OK
Number of successes: 1
Number of failures: 0
Operation time to live: Forever

Let start constant ping to 4.4.4.4, then disconnect the cable on MPLS line, and do tracert to 4.4.4.4…
FEI-R-4331-1#ping 4.4.4.4 repeat 6000
Type escape sequence to abort.
Sending 6000, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
… deleted for clarity
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! – lost 1 ping
… deleted for clarity

Success rate is 99 percent (5998/6000), round-trip min/avg/max = 1/1/7 ms

FEI-R-4331-1#traceroute 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 1.1.1.2 1 msec 1 msec 1 msec
2 30.30.30.32 1 msec *  1 msec – communication goes over backup line

FEI-R-4331-1#

Switching it back to MPLS:
FEI-R-4331-1#ping 4.4.4.4 repeat 6000
Type escape sequence to abort.
Sending 6000, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! – lost 1 ping while MPLS interface came up.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (5999/6000), round-trip min/avg/max = 1/1/6 ms
FEI-R-4331-1#

FEI-R-4331-1#traceroute 4.4.4.4  – route is switched back automatically to the higher priority one.
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 10.238.254.134 1 msec 1 msec 0 msec
2 20.20.20.22 0 msec *  1 msec

FEI-R-4331-1#

Here it goes. Very useful feature that saved valuable time to most of my customers base.

 

Advertisements

There is always something we need to get back to. How the packet flows and which check happens first, so here we go.

A link to Cisco’s TAC engineers document that explain it all..

Packet flow

8.3 introduced network objects to the configuration where you can to define a single host a range of ip addresses or single subnet. It is within this objects definition where the NAT is configured.

For auto NAT or Dynamic PAT:

#object network inside-net
subnet 10.0.0.0 255.255.255.0
nat (inside,outside) dynamic interface

– In this case we specified how the ASA will translate the source ip address in the IP packet for the networks subnet when traversing from the local interface or the inside interface to the mapped interface or the outside interface. We’ve also stated that this is dynamic nat and we’re going to translate all of the hosts to the interface IP address of the firewall by using port address translation. Notice that we entered NAT command within the object definition so this configuration tells a firewall how to perform address translation on this specific object which in this case is inside network.
– If we look at the running configuration of the the firewall you’ll see that the ASA splits the object configuration into two parts:
first defines the object subnet and the second identifies the NAT configuration for the object so the object will appear twice in the configuration.
– In version 8.3 static and global commands are gone and all that configuration is done within NAT command

-/- -/- -/- -/- -/- -/- -/-

DMZ

ScreenClip[2]
Lets specify translation so that the server in the DMZ is statically translated to a global ip on the outside of the ASA. In this case we’ll translate the DMZ server 192.168.1.23 to 209.165.201.28.

1. define an object for the server and specify ip address for this particual host and configure NAT command within the object to provide a static one to one mapping

#object network dmz-webserver
host 192.168.1.23
nat (dmz.outside) static 209.165.201.28

now users on the internet can send packets to the global ip address of 209.165.201.28 and the ASА will provide translation and change the destination ip address in the packet to the local 192.168.1.23 server ip on the DMZ .

ASA still has to be specifically configured with ACL and access-group commands. ACL permitting the inbound access need to define the real ip address not the mapped IP address.

#access-list outside_in permit ip any host 192.168.1.23
#access-group outside_in in int outside

Now, check NAT config on ASA (display object definitions and then the NAT configurations applied within those objects):

# show run object
# show run nat

#show nat – display the nat table of the ASA

-/- -/- -/- -/- -/- -/- -/-

A new feature of 8.3 is that you can specify the translation for an object between multiple interfaces in just one line.
SC2
for example if we want ASA to perform address translation for DMZ server on any mapped interface of the ASA, then we could just use the any keyword in the map command.

#object netwrok dmz-webserver
nat (dmz,any) static 209.165.201.28

Now when hosts on any interface on the firewall need to have access to dmz server, they can connect directly to the mapped interface of 209.165.201.28. So our inside host can connect to this server using mapped interface if they have access.

-/- -/- -/- -/- -/- -/- -/-

Here we have two servers in DMZ hosting different services (http, ftp). We can use the same outside global mapped ip if we use pat to specify port address translation. In this case we use outside interface of ASA as mapped IP.
SC3
First create a object for dmz server and apply a NAT configuration to the object specifying that ASA should perform a static translation from dmz interface to the outside interface as the mapped ip, then we specify the local and mapped service port. In this case both are www since we dont change port in the translation:

#object network dmz-webserver
host 192.168.1.25
nat (dmz,outside) static interface service tcp www www

After doing this for www we will do the same for ftp server:

#object network ftp-webserver
host 192.168.1.25
nat (dmz,outside) static interface service tcp ftp ftp

#show run object
#show run nat

-/- -/- -/- -/- -/- -/- -/-

So far we’ve defined objects and specified how to translate their source ip addresses when they traverse certain interfaces of the ASA. However when using autonat you cannot specify that the ASA should only perfrom translation when host access certain destinations and you cannot specify how the ASA might translate the destination ip of the packet.
SC4
To do this we need to use manual nat or twice nat. Manual nat is not configured under an object definition; instead is configured separately in the configuration and takes objects as arguments to specify the translation.

#nat (real,mapped) source static object1 object2 destination _

Looking back at our diagram let’s say whenever internal users on the inside interface access http://www.cisco.com, the ASA should translate their source address to 209.165.201.10.
This differs from case when internal users access any other web site on the internet when they should be translated to the ASA outside interface ip of 209.165.201.2

To accomplish this we first need to create an object for each argument in the nat command one for the translated ip that we want to translate the users to:

#object network translated-ip
host 209.165.201.10

One for the ip address of cisco.com

#object network cisco-dot-com
host 198.133.219.25

We already have one for inside user subnet. Then to configure the manual NAT entry will add it in a base configuration of the ASA and not under an object:

#nat (inside,outside) source dynamic inside-nat translated-ip destination static cisco-dot-com cisco-dot-com

#sho run nat

This command specify that we provide translation from inside (inside) to the mapped ip of outside (outside) interface; in this case we will translate source of the packet (source), we are going to do dynamic port translation (dynamic) when the source of the packet matched inside network (object inside-nat) we’re going to translate it to the global ip specified in the translated-ip object (translated-ip).
With manual NAT you can specify the destination of the ip packet that you want to match and that is why we have cisco-dot-com as a destination ip

With this in place you can use packet tracert to inject a simulated packet thru the inside interface of the firewall. and send it to cisco.com and then to another ip address to see how firewall is going to translate packets differently.

# packet-tracer input inside tcp 10.0.0.40 4444 198.133.219.25 80

sending packet from inside interface sourced from 10.0.0.40 on port 4444, destined to cisco.com on port 80. Enter will inject this packet to firewall and show us exactly what is happening with packet. At the end of window, check NAT and note how ASA will translate source ip of the packet destined to cisco.com

Then, change last octet to something other then 25 and ASA will not match manual nat rule and should change ip from auto nat:

# packet-tracer input inside tcp 10.0.0.40 4444 198.133.219.31 80

-/- -/- -/- -/- -/- -/- -/-

Policy NAT exemption when ASA is asked not to translate IP address when traffic is destined to certain destinations (like thru VPN tunnel) so it does not translate any VPN packets from the internal network that it’s destined to our remote VPN subnets.
SC5
We have to use manual NAT.
Create object for remote vpn subnets with range of ip addresses of our remote subnets:

#object network vpn-subnets
range 10.1.0.0 10.5.255.255

Manual nat will tell the ASA to simply maintain the internal network ip address when accessing the remote vpn subnets. Now when internal user accessing remote hosts their packets will go across vpn tunnel without any translation,

#nat (inside,outside) source static inside-net inside-net destination static vpn-subnets vpn-subnets

PKI Theory

Posted: August 11, 2014 in Cisco Security - Firewalls

Files on ASA when ASA is a CA (located in LOCAL-CA-SERVER folder):

LOCAL-CA-SERVER.ser is a clear-text file containing the serial number of issued certificates.
LOCAL-CA-SERVER.cdb is clear-text file containing information about issued certificates.
LOCAL-CA-SERVER.udb is a clear-text file containing information about enrolled users.
LOCAL-CA-SERVER.crl is a password-encrypted file containing information about revoked certificates.
LOCAL-CA-SERVER.p12 is a password-encrypted file containing the RSA public/private key pair and the self-signed certificate.

 

If you need to delete file form ASA flash:
delete /recursive /noconfirm flash:/LOCAL-CA-SERVER.

ASA04-5520(config)# crypto ca server
ASA04-5520(config-ca-server)# keysize 2048
ASA04-5520(config-ca-server)# keysize server 2048
ASA04-5520(config)# domain-name cciesecblog.com
ASA04-5520(config-ca-server)# smtp from-address ASA4@cciesecblog.com
ASA04-5520(config-ca-server)# smtp subject Use this URL to enroll with INE CA
ASA04-5520(config-ca-server)# lifetime certificate 730
ASA04-5520(config-ca-server)# publish-crl VLAN27 443
ASA04-5520(config-ca-server)# no shut

% Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or press return to exit
% Passphrase must be more than 7 characters. Try again
% or press Return to exit
Passphrase: **********
Re-enter passphrase: **********
Keypair generation process begin. Please wait…
Completed generation of the certificate and keypair…
Archiving certificate and keypair to storage… Complete
INFO:
Certificate Server enabled.

ASA04-5520(config)# webvpn
ASA04-5520(config-webvpn)# enable vlAN27
ASA04-5520(config)# crypto ca server user-db add RTR01 email rtr01@cciesecblog.com dn CN=rtr01
ASA04-5520(config)# crypto ca server user-db add RTR02 email rtr02@cciesecblog.com dn CN=rtr02
ASA04-5520(config)# crypto ca server user-db allow user rtr01
ASA04-5520(config)# crypto ca server user-db allow user rtr02

ASA04-5520(config)# sh crypto ca server

Certificate Server LOCAL-CA-SERVER:
Status: enabled
State: enabled
Server’s configuration is locked  (enter “shutdown” to unlock it)
Issuer name: CN=ASA04-5520
CA certificate fingerprint/thumbprint: (MD5)
2bc755ad 00c06f8c 741c1fb8 2556eb97
CA certificate fingerprint/thumbprint: (SHA1)
564f7919 cf0bf615 cfe8813d cf153468 1787fdb4
Last certificate issued serial number: 0x1
CA certificate expiration timer: 15:03:17 UTC Aug 19 2016
CRL NextUpdate timer: 21:03:17 UTC Aug 20 2014
Current primary storage dir: flash:/LOCAL-CA-SERVER/

Auto-Rollover configured, overlap period 30 days
Autorollover timer: 15:03:17 UTC Jul 20 2016

WARNING: Configuration has been modified and needs to be saved!!

ASA04-5520(config)#
ASA04-5520(config)# sh asp table socket

Protocol  Socket    Local Address               Foreign Address         State
TCP       000034bf  136.1.27.8:443              0.0.0.0:*               LISTEN
DTLS      0000636f  136.1.27.8:443              0.0.0.0:*               LISTEN
ASA04-5520(config)#

ASA04-5520(config)# show crypto ca server user-db username rtr01
username: rtr01
email:    rtr01@cciesecblog.com
dn:       CN=RTR01
allowed:  15:06:24 UTC Sat Aug 23 2014
notified: 1 times
enrollment status: Allowed to Enroll

ASA04-5520(config)#

ASA04-5520(config)#  show crypto ca server user-db        
username: rtr01
email:    rtr01@cciesecblog.com
dn:       CN=RTR01
allowed:  15:06:24 UTC Sat Aug 23 2014
notified: 1 times
enrollment status: Allowed to Enroll

username: rtr02
email:    rtr02@cciesecblog.com
dn:       CN=RTR02
allowed:  15:06:26 UTC Sat Aug 23 2014
notified: 1 times
enrollment status: Allowed to Enroll

AASA04-5520(config)# sh crypto ca server

Certificate Server LOCAL-CA-SERVER:
Status: enabled
State: enabled
Server’s configuration is locked  (enter “shutdown” to unlock it)
Issuer name: CN=ASA04-5520
CA certificate fingerprint/thumbprint: (MD5)
2bc755ad 00c06f8c 741c1fb8 2556eb97
CA certificate fingerprint/thumbprint: (SHA1)
564f7919 cf0bf615 cfe8813d cf153468 1787fdb4
Last certificate issued serial number: 0x1
CA certificate expiration timer: 15:03:17 UTC Aug 19 2016
CRL NextUpdate timer: 21:03:17 UTC Aug 20 2014
Current primary storage dir: flash:/LOCAL-CA-SERVER/

Auto-Rollover configured, overlap period 30 days
Autorollover timer: 15:03:17 UTC Jul 20 2016

WARNING: Configuration has been modified and needs to be saved!!
ASA04-5520(config)# crypto ca server user-db show-otp user rtr01
Username: rtr01
OTP: 9C14982D1F48AA76
Enrollment Allowed Until: 15:06:24 UTC Sat Aug 23 2014

 

 

PKI (Public Key Infrastructure) is system managing the public key cryptography also known as asymmetric cryptography. PKI uses set of protocols, standards, services and policies to achieve this goal. PKI uses a pair of two keys mathematically matched. One is used for encryption process another is used for decryption process. These are private and public keys. Private key is know only to its owner and public key is publicly available.

Symmetric cryptography uses single key for both encryption and decryption process.

Confidentiality. A message encrypted with a public key can only be decrypted by its corresponding private key, which is known only to its owner, thus ensuring that the message can be read/decrypted only by the private-key owner for which the message was generated.

Authentication/integrity. A message encrypted with a private key can only be decrypted by its corresponding public key; anyone can get the public-key and thus read/decrypt the message, but because the private-key resides only with the owner, it guarantees identity of the message source. This process ensures authenticity and non-repudiation of the message (also known as digital signature); if combined with a hash function, it can also provide message integrity.

How to ensure that I receive a public key from a trusted sources? The role of a Certificate Authority (CA) exists to create the necessary trust level between two peers through the use of identities, also called digital certificates.

The following is a simplified step-by-step guide for issuing digital certificates through the CA:

1 – The CA generates its own pair of RSA/EC public/private keys, issues a self-signed digital certificate, and becomes a CA (the private key of the CA should be safeguarded and never be shared with others).
2 – Each client requiring a digital certificate generates its own pair of public/private RSA/EC keys.
3 – The public key of the client, along with other information required to prove its identity, is submitted to the CA in the form of a Certificate Signing Request (the request is signed with the client private key so that the CA can verify the authenticity of the request).
4 – The CA provides a digital signature to the submitted information using its own private key, and the result is a digital certificate.
5 – The resulting digital certificate is issued back to the requesting client.

A digital certificate (aka public key certificate) is like a passport containing information (similar to a personal identification number) that uniquely identifies you; to be recognized as valid, it also requires the signature of the issuer (the CA). To be universally valid, it needs a certain format or structure and a minimum amount of information, which is described in X.509 standard. At a minimum, it must make use of the following:

Version           –       Based on the version and the certificate template being used, the certificate is valid for certain purposes (for example, it can be used for encryption but not for digital signature).
Serial Number  –  Uniquely identifies a certificate issued by a CA.
Issuer                 –  Information about the CA, such as Common Name or FQDN.
Validity              – The start/end time for which the certificate is valid and can be used.
Subject               – Information about the client, such as Common Name or FQDN.
Public Key         – The client’s public key data and algorithm.
Certificate Signature  – The CA signature data and algorithm.

When two peers need to perform authentication using digital certificates (such as in SSL or IPsec VPNs), the following is required:
– Both peers exchange their certificates, which need to be valid at that time.
– Certificates can be issued by different certificate authorities.
– For one peer to verify the identity from the presented certificate of the remote peer, it must read the digital signature from the certificate, so it needs the know and trust the public key of the issuing certificate authority.

The Certificate Signing Request (CSR) required to obtain an X.509 digital certificate also uses a standard format. At a minimum, the CSR contains the public key and one or more of the following fields, which will appear in the Subject field of the certificate:
Common Name or Distinguished Name (FQDN)
Organizational Unit and Organization
Town and Country
E-mail Address

In general, a CSR can be generated and submitted using Active Directory Certificate Services (ADCS), Simple Certificate Enrollment Protocol/ Network Device Enrollment Service (SCEP/NDES), Web enrollment, and Manual (terminal-based) enrollment. When the CA issues/approves the certificate, it must be installed/imported by the requesting client.

Some standard certificate file formats are:

PEM (Privacy Enhanced Mail) == A base64 encoded file containing one or more digital certificates along with associated private keys, optionally protected by a password.

Base64 ==  A binary format file containing a single certificate, without support for certificate chain or private keys

P7B/PKCS#7 (Cryptographic Message Syntax Standard) == A base64 encoded file containing one or more certificates and all CA certificates in the certification chain, without support for the private keys of the certificates.

DER (Distinguished Encoding Rules) ==  A binary format file containing a single certificate, without support for certificate chain or private keys.

PFX/PKCS#12 (Personal Information Exchange) == A binary format file containing one or more digital certificates along with associated private keys and all CA certificates in the certification chain, optionally protected by a password.
The digital certificate provides only the public information, but for it to be usable by its owner, it needs the associated private key. For this reason, if you want to export a certificate for backup purposes and make it usable on import, you must use the PEM or PKCS#12 formats.

A digital certificate can be revoked at any time, such as when compromised or no longer used by its owner. For this reason, when a trust relationship based on certificates is established, it may be desirable to first determine whether the received certificate of a remote peer is still valid. The only entity that can revoke a certificate (invalidate it before it expires according to its validity period) is the issuer, and this is the CA. There are two options for verifying a certificate:

The CA can publish a Certificate Revocation List (CRL), which contains the serial numbers of certificates in revoked or hold state. The CA refreshes this list periodically but not instantly, and any client can download and cache it for a period of time; this method of validating certificates is not 100% accurate because it does not happen in real time.
Using Online Certificate Status Protocol (OCSP). Each time a digital certificate is received, an OCSP query is sent to ask about its status based on the serial number; this method is 100% accurate because it is not based on a periodically refreshed list, but on a real-time query/response.

In large PKI deployments, you may experience performance issues caused by a high number of CSRs, or you may want to have multiple CAs geographically dispersed within the same PKI system. The components of a hierarchical PKI are:

Root CA. This is the first CA installed in your PKI deployment.
Highest level in a hierarchical PKI.
Can act as a fully functional CA (manage client certificate’s life cycle).
Has a self-signed digital certificate with the highest lifetime in the PKI.
Can delegate all the CA functions to subordinate CAs.
Can delegate part of its functions to RAs.
With Subordinate CA’s, the Root CA is taken offline for security reasons and is only responsible for issuing certificates to subordinate CAs.

Subordinate CA. This is the second CA installed in your PKI.
Second-highest level in a hierarchical PKI if subordinate to the root CA.
Can also be subordinate to another subordinate CA.
Can act as a fully functional CA (manage client certificate’s life cycle).
Has a digital certificate received from the root/subordinate CA with a high lifetime.
Can delegate all the CA functions to other subordinate CAs.
Can delegate part of its functions to RAs.

Registration Authority. This is an optional role in your PKI.
Acts as a proxy between clients and root/subordinate CA.
Its functions are performed by default by the root/subordinate CA.
Authenticates and authorizes client certificate requests.
Forwards valid and approved requests to the subordinate/root CA.
Cannot issue client certificates.

 

 

 

 

 

RIP and beyond

Posted: August 7, 2014 in Cisco Security - Firewalls

ASA supports RIPv1 and RIPv2 dynamic routing (a single process) only for IPv4.

Enable RIP process – activates RIP globally, router rip. Version1 or version2 can be configured using the process-level command version [1|2].

Disable auto-summary – global command no auto-summary, it disables the classful network boundary auto-summarization function of RIP, which by default is enabled.

Enable interfaces for RIP – process-level command network <classful_network>, it activates sending and receiving of RIP multicast updates on interfaces matching the command. Also, subnets matched by the command are included in the RIP updates/advertisements.

Define passive interfaces (optional) – process-level command passive-interface <nameif>, it disables sending of RIP updates, but received updates will still be allowed and processed.

Enable authentication (optional) – interface-level commands rip authentication mode [text|md5] and rip authentication key 0 <key_string> key_id <key_nr>, it enables clear-text or MD5 authentication for all RIP updates on respective interfaces. A single key can be configured per-interface. If received, RIP updates that are not authenticated correctly will be discarded.

Originate default route (optional) – process-level command default-information originate [route-map <name>], it activates sending of default route in RIP updates. Route-map is optional and can be used to set the metric value.

Filter routing updates – process-level command distribute-list <acl_name> [in|out] interface <nameif>, it filters inbound or outbound updates according to the rules from the ACL. Only standard ACL is allowed, so it can only match on prefix, not on prefix-length.

 

Configuration steps:

ASA2:
route-map RIP-MAP permit 10
set metric 10
!
access-list RIP-VLAN26 deny any
!
router rip
version 2
no auto-summary
default-information originate route-map RIP-MAP
network 136.1.0.0
network 172.16.0.0
passive-interface VLAN26
distribute-list RIP-VLAN26 in interface VLAN26
!
interface Management0/0
rip authentication mode text
rip authentication key 0 SLAB key_id 1
!
interface Ethernet0/1.29
rip authentication mode md5
rip authentication key 0 JAK key_id 1

 

~~~~~ Router 1 config:

router rip
version 2
no auto-summary
network 136.1.0.0
network 150.1.0.0
!
key chain RIP
key 1
key-string 0 JAK
!
interface gigabitEthernet0/0
ip rip authentication mode md5
ip rip authentication key-chain RIP

~~~~~ Router 2 config:

router rip
version 2
no auto-summary
network 136.1.0.0
network 150.1.0.0
!
key chain RIP
key 1
key-string 0 SLAB
!
interface gigabitEthernet0/0.19
ip rip authentication mode text
ip rip authentication key-chain RIP

RTR01#sh ip route rip | b Gateway
Gateway of last resort is 136.1.19.16 to network 0.0.0.0

R*    0.0.0.0/0 [120/10] via 136.1.19.16, 00:00:14, FastEthernet0/0.19
136.1.0.0/16 is variably subnetted, 9 subnets, 2 masks
R        136.1.29.0/24 [120/1] via 136.1.19.16, 00:00:14, FastEthernet0/0.19
R        136.1.56.0/24 [120/2] via 136.1.19.16, 00:00:14, FastEthernet0/0.19
150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
R        150.1.0.0/16 [120/2] via 136.1.19.16, 00:00:14, FastEthernet0/0.19
RTR01#sh ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is “rip”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 24 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface             Send  Recv  Triggered RIP  Key-chain
FastEthernet0/0.19    2     2                    RIP
FastEthernet0/0.27    2     2
FastEthernet0/1       2     2
Loopback0             2     2
Loopback1             2     2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
136.1.0.0
150.1.0.0
Routing Information Sources:
Gateway         Distance      Last Update
136.1.19.16          120      00:00:21
Distance: (default is 120)

RTR01#debug ip rip
*Aug  7 17:08:59.032: RIP: received packet with text authentication SLAB
*Aug  7 17:08:59.032: RIP: received v2 update from 136.1.19.16 on FastEthernet0/0.19
*Aug  7 17:08:59.032:      0.0.0.0/0 via 0.0.0.0 in 10 hops
*Aug  7 17:08:59.032:      136.1.29.0/24 via 0.0.0.0 in 1 hops
*Aug  7 17:09:01.804: RIP: sending v2 update to 224.0.0.9 via Loopback1 (150.1.11.11)
*Aug  7 17:09:01.804: RIP: build update entries
*Aug  7 17:09:01.804:   0.0.0.0/0 via 0.0.0.0, metric 11, tag 0
*Aug  7 17:09:01.804:   136.1.19.0/24 via 0.0.0.0, metric 1, tag 0
*Aug  7 17:09:01.804:   136.1.27.0/24 via 0.0.0.0, metric 1, tag 0
*Aug  7 17:09:01.804:   136.1.29.0/24 via 0.0.0.0, metric 2, tag 0
*Aug  7 17:09:01.804:   136.1.49.0/24 via 0.0.0.0, metric 1, tag 0
*Aug  7 17:09:01.804:   150.1.1.1/32 via 0.0.0.0, metric 1, tag 0
*Aug  7 17:09:01.804: RIP: ignored v2 packet from 150.1.11.11 (sourced from one of our addresses)
*Aug  7 17:09:04.972: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0.27 (136.1.27.1)
*Aug  7 17:09:04.972: RIP: build update entries
*Aug  7 17:09:04.972:   0.0.0.0/0 via 0.0.0.0, metric 11, tag 0
*Aug  7 17:09:04.972:   136.1.19.0/24 via 0.0.0.0, metric 1, tag 0
*Aug  7 17:09:04.972:   136.1.29.0/24 via 0.0.0.0, metric 2, tag 0
*Aug  7 17:09:04.972:   136.1.49.0/24 via 0.0.0.0, metric 1, tag 0
*Aug  7 17:09:04.972:   150.1.1.1/32 via 0.0.0.0, metric 1, tag 0
*Aug  7 17:09:04.972:   150.1.11.11/32 via 0.0.0.0, metric 1, tag 0
~~~~~~~~~~~~~~~

ASA02-5510# sh route | in R
Codes: C – connected, S – static, I – IGRP, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
* – candidate default, U – per-user static route, o – ODR
R    136.1.56.0 255.255.255.0 [120/1] via 136.1.29.2, 0:01:08, VLAN29
R    136.1.49.0 255.255.255.0 [120/1] via 136.1.19.1, 0:00:00, VLAN19
R    150.1.11.11 255.255.255.255 [120/1] via 136.1.19.1, 0:00:00, VLAN19
R    150.1.1.1 255.255.255.255 [120/1] via 136.1.19.1, 0:00:00, VLAN19
R    150.1.0.0 255.255.0.0 [120/1] via 136.1.29.2, 0:01:08, VLAN29
ASA02-5510#

First, must install a Cisco ad agent on windows server and have Microsoft AD up and running. Agent must be part or active directory.
On AD agent:

C:\cd IBF
C:\IBF\cd CLI
C:\IBF\cd CLI>adactrl.exe show running

C:\IBF\cd CLI>adacfg client create -name ASA02 -ip 172.16.10.1 -secret password

C:\IBF\cd CLI>adacfg client list
C:\IBF\cd CLI>adacfg client erase -name ACHILE-AD

C:\IBF\cd CLI>adacfg dc list
C:\IBF\cd CLI>adacfg dc erase -name AD-POC

On firewall, enter below commands:

object-group user FIREWALL
user cciesecblog\user1
user-group cciesecblog\\ccielab

access-list VLAN19_INBOUND extended permit ip any any
access-list VLAN19_INBOUND extended permit ip object-group-user FIREWALL any any

aaa-server IDENTITY protocol radius
ad-agent-mode

aaa-server IDENTITY (VLAN26) host 172.16.10.100
key password

aaa-server AD-SERVER protocol ldap

aaa-server AD-SERVER (VLAN26) host 172.16.10.200
ldap-base-dn dc=cciesecblog,dc=com
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password Summer2100!
ldap-login-dn cn=administrator,cn=Users,dc=cciesecblog,dc=com
server-type microsoft

user-identity domain cciesecblog aaa-server AD-SERVER
user-identity default-domain cciesecblog
user-identity action ad-agent-down disable-user-identity-rule
user-identity action domain-controller-down cciesecblog disable-user-identity-rule
user-identity inactive-user-timer minutes 30
user-identity poll-import-user-group-timer hours 1
user-identity ad-agent aaa-server IDENTITY

~~~~~~~~~~~~~~

ASA02-5510(config)# test aaa-server ad-agent IDENTITY
Server IP Address or name:
Server IP Address or name:
Server IP Address or name: 172.16.10.100
INFO: Attempting Ad-agent test to IP address <172.16.10.100> (timeout: 12 seconds)
INFO: Ad-agent Successful
ASA02-5510(config)#

ASA02-5510(config)# show user-identity ad-agent
Primary AD Agent:
Status                    up (registered)
Mode:                     full-download
IP address:               172.16.10.100
Authentication port:      udp/1645
Accounting port:          udp/1646
ASA listening port:       udp/3799
Interface:                VLAN26
Up time:                  39 secs
Average RTT:              0 msec

AD Domain Status:
Domain CCIESECBLOG:       up
ASA02-5510(config)#

ASA02-5510(config)# debug ldap 255
debug ldap  enabled at level 255

ASA02-5510(config)# logging console 7

ASA02-5510(config)# show user-identity ad-groups cciesecblog

[25] Session Start
[25] New request Session, context 0xac3d1014, reqType = Unknown
[25] Fiber started
[25] Creating LDAP context with uri=ldap://172.16.10.200:389
[25] Connect to LDAP server: ldap://172.16.10.200:389, status = Successful
[25] supportedLDAPVersion: value = 3
[25] supportedLDAPVersion: value = 2
[25] Binding as ldapuser
[25] Performing Simple authentication for ldapuser to 172.16.10.200
[25] Simple authentication for ldapuser returned code (49) Invalid credentials
[25] Failed to bind as administrator returned code (-1) Can’t contact LDAP server
[25] Fiber exit Tx=212 bytes Rx=608 bytes, status=-2
[25] Session End

ASA02-5510# sh user-identity ip-of-user user1
cciesecblog\136.1.27.150 (Login)
ASA02-5510#

ASA02-5510# show user-identity user active user cciesecblog\user1 list detail
cciesecblog\user1: 26 active conns; idle 0 mins
136.1.27.150: login 0 mins, idle 0 mins, 26 active conns
ASA02-5510#

ASA02-5510# sh conn user cciesecblog\user1
27 in use, 40 most used
UDP VLAN26 172.16.10.200:53 VLAN19 (cciesecblog\user1)136.1.27.150:1025, idle 0:00:00, bytes 220, flags –
UDP VLAN26 172.16.10.200:389 VLAN19 (cciesecblog\user1)136.1.27.150:1083, idle 0:00:31, bytes 347, flags –
UDP VLAN26 172.16.10.200:389 VLAN19 (cciesecblog\user1)136.1.27.150:1080, idle 0:00:37, bytes 347, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1075, idle 0:00:38, bytes 2804, flags –
UDP VLAN26 172.16.10.200:389 VLAN19 (cciesecblog\user1)136.1.27.150:1064, idle 0:00:56, bytes 347, flags –
UDP VLAN26 172.16.10.200:138 VLAN19 (cciesecblog\user1)136.1.27.150:138, idle 0:00:56, bytes 177, flags –
UDP VLAN26 172.16.10.200:137 VLAN19 (cciesecblog\user1)136.1.27.150:137, idle 0:00:56, bytes 243, flags –
UDP VLAN26 172.16.10.200:389 VLAN19 (cciesecblog\user1)136.1.27.150:1062, idle 0:01:06, bytes 347, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1060, idle 0:01:06, bytes 2763, flags –
UDP VLAN26 172.16.10.200:389 VLAN19 (cciesecblog\user1)136.1.27.150:1059, idle 0:01:10, bytes 347, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1055, idle 0:01:11, bytes 2763, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1054, idle 0:01:11, bytes 2763, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1052, idle 0:01:11, bytes 2760, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1050, idle 0:01:11, bytes 402, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1048, idle 0:01:14, bytes 402, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1045, idle 0:01:19, bytes 397, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1044, idle 0:01:27, bytes 2807, flags –
UDP VLAN26 172.16.10.200:123 VLAN19 (cciesecblog\user1)136.1.27.150:123, idle 0:01:28, bytes 136, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1037, idle 0:01:31, bytes 2807, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1036, idle 0:01:31, bytes 2807, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1034, idle 0:01:31, bytes 421, flags –
UDP VLAN26 172.16.10.200:389 VLAN19 (cciesecblog\user1)136.1.27.150:1027, idle 0:01:32, bytes 438, flags –
UDP VLAN26 172.16.10.200:88 VLAN19 (cciesecblog\user1)136.1.27.150:1120, idle 0:01:57, bytes 2807, flags –
UDP VLAN26 172.16.10.200:389 VLAN19 (cciesecblog\user1)136.1.27.150:1119, idle 0:02:00, bytes 347, flags –
TCP VLAN26 172.16.10.200:49155 VLAN19 (cciesecblog\user1) 136.1.27.150:1117, idle 0:02:02, bytes 638, flags UIO
ASA02-5510#

ASA02-5510# show user-identity ad-users cciesecblog filter user1

Domain:cciesecblog      AAA Server Group: AD-SERVER
User list retrieved successfully
Number of Active Directory Users: 1
dn: CN=user1,CN=Users,DC=cciesecblog,DC=com
sAMAccountName: user1

ASA02-5510#

ASA02-5510# sh user-identity ad-groups cciesecblog filter ccielab

Domain:cciesecblog      AAA Server Group: AD-SERVER
Group list retrieved successfully
Number of Active Directory Groups: 1
dn: CN=ccielab,CN=Users,DC=cciesecblog,DC=com
sAMAccountName: ccielab

ASA02-5510#

ASA02-5510# show user-identity ad-groups cciesecblog

Domain:cciesecblog      AAA Server Group: AD-SERVER
Group list retrieved successfully
Number of Active Directory Groups: 38
dn: CN=Administrators,CN=Builtin,DC=cciesecblog,DC=com
sAMAccountName: Administrators

ASA supports the following object group types:

Network           = matching on IPv4/IPv6 hosts or subnets.
Protocol            = matching on layer3/layer4 IP protocols.
ICMP-Type      = matching on ICMP Types.
Service              = matching on TCP/UDP ports. A service object group supports multiple sub-types: TCP, UDP, TCP-UDP, Generic (matching on a mixture of source or destination TCP/UDP ports).

ASA02-5510(config)# sh object-group

object-group network R2
network-object host 150.1.22.22
network-object 136.1.29.0 255.255.255.0

object-group network SUBNETS
network-object 172.16.10.0 255.255.255.0
network-object 136.1.19.0 255.255.255.0

object-group network R1-LOOPBACK1
network-object 150.1.11.0 255.255.255.0

object-group service TELNET tcp
port-object eq telnet

object-group service TFTP udp
port-object eq tftp

object-group service OTHER-PORTS
service-object tcp destination eq ftp
service-object udp destination eq ntp

object-group network ALL
group-object SUBNETS
group-object R1-LOOPBACK1

ASA02-5510# sh run access-list
access-list VLAN29 extended permit tcp object-group R2 object-group ALL object-group TELNET
access-list VLAN29 extended permit udp object-group R2 object-group ALL object-group TFTP
access-list VLAN29 extended permit object-group OTHER-PORTS object-group R2 object-group ALL

access-group VLAN29_INBOUND in interface VLAN29

object-group
icmp-type            Specifies a group of ICMP types, such as echo
network               Specifies a group of host or subnet IP addresses
protocol               Specifies a group of protocols, such as TCP, etc
service                 Specifies a group of TCP/UDP ports/services
user                      Specifies single user, local or import user group

network-object-group
description        Specify description text
group-object     Configure an object group as an object
help                     Help for network object-group configuration commands
network-object  Configure a network object
no                        Remove an object or description from object-group

network-object-group mode commands/options:
Hostname or A.B.C.D                   Enter an IPv4 network address
X:X:X:X::X/<0-128>                    Enter an IPv6 prefix
host                                                Enter this keyword to specify a single host object
object                                             Enter this keyword to specify a network object

object-group service TELNET
tcp                   Specifies this object-group is for TCP protocol only
tcp-udp          Specifies this object-group is for both TCP & UDP
udp                 Specifies this object-group is for UDP protocol only

service-object-group
description             Specify description text
group-object          Configure an object group as an object
help                          Help for service object-group configuration commands
no                              Remove an object or description from object-group
port-object              Configure a port object
object-group service OTHER-PORTS
description            Specify description text
group-object         Configure an object group as an object
help                         Help for service object-group configuration commands
no                            Remove an object or description from object-group
service-object       Configure a service object

service-object tcp
dual-service-object-group mode commands/options:
destination             Keyword to specify destination
source                     Keyword to specify source

ASA02-5510(config-service-object-group)# service-object tcp eq 21
ASA02-5510(config-service-object-group)# service-object udp eq 123