Networking-Blog

My WordPress Blog

Cisco Multilayer Switch+EtherChannel

Implementation of an MPLS Router  Cisco 3900 Connected to a
Cisco 2960G MultiLayer Switch Running HSRP. Cisco 2960 Multilayer switch
further providing Trunk to Cisco 2960G MultiLayer Switch providing
routing of 4 Vlan’s with EtherChannel configured part of channel-group 1 & 2.
!
EtherChannel provides incremental trunk speeds between Fast Ethernet,
Gigabit Ethernet, and 10 Gigabit Ethernet. EtherChannel combines multiple Fast
Ethernet up to 800Mbps, Gigabit Ethernet up to 8Gbps , and 10 Gigabit Ethernet
up to 80Gbps.
!
Fast EtherChannel is a technology-leveraging, standards-based Fast Ethernet
used in parallel to provide the additional bandwidth network backbones require today.
It provides flexible, scalable bandwidth with resiliency and load sharing across links
for switches, router interfaces and servers. Supports up to eight links per channel.
!
!
HQ GW1-Cisco-2960-PRI-HSRP

track 1 interface Port-channel1 line-protocol
!
interface Loopback200
description WW_management
ip address 85.234.95.197 255.255.255.255
!
!
interface Port-channel1
no ip address
!
interface Port-channel1.10
description amari_it_vlan
encapsulation dot1Q 10
ip address 10.1.1.7 255.255.0.0
ip ospf network point-to-multipoint
ip ospf cost 10
ip ospf 1 area 0
standby 1 ip 10.1.1.6
standby 1 priority 120
standby 1 preempt
standby 1 track 1 decrement 10
!
interface Port-channel1.19
description amari_it_office_vlan
encapsulation dot1Q 19
ip address 10.99.1.7 255.255.0.0
standby 3 ip 10.99.1.6
standby 3 priority 120
standby 3 preempt
standby 3 track 1 decrement 10
!
interface Port-channel1.20
description amari_st_vlan
encapsulation dot1Q 20
ip address 10.33.1.7 255.255.0.0
standby 2 ip 10.33.1.6
standby 2 priority 120
standby 2 preempt
standby 2 track 1 decrement 10
!
interface Port-channel1.99
description amari_bt_mgmt_vlan
encapsulation dot1Q 99
ip address 10.214.1.7 255.255.0.0
standby 4 ip 10.214.1.6
standby 4 priority 120
standby 4 preempt
standby 4 track 1 decrement 10
!
interface GigabitEthernet0/0
description ww_mgmt_access
ip address 172.200.200.1 255.255.255.0
!
!
interface GigabitEthernet0/1
description etherchannel_channel-port1_member
no ip address
channel-group 1
!
interface GigabitEthernet0/2
description etherchannel_channel-port1_member
no ip address
channel-group 1
!
ip route 0.0.0.0 0.0.0.0 10.200.0.1
!
router ospf 1
log-adjacency-changes
redistribute static subnets
passive-interface Port-channel1.19
passive-interface Port-channel1.20
passive-interface Port-channel1.99
!
!
ip access-list extended reroute
permit ip any 10.3.0.0 0.0.0.255
permit ip any object-group reroute log
!
route-map reroute permit 10
match ip address reroute
set ip next-hop 10.1.1.1
!
!
HQ GW2-Cisco-2960-SEC-HSRP

interface Loopback200
description WW_management
ip address 85.234.95.198 255.255.255.255
!
!
interface Port-channel1
no ip address
!
interface Port-channel1.10
description amari_it_vlan
encapsulation dot1Q 10
ip address 10.1.1.8 255.255.0.0
ip ospf network point-to-multipoint
ip ospf cost 100
ip ospf 1 area 0
standby 1 ip 10.1.1.6
standby 1 priority 110
standby 1 preempt
standby 1 track 1 decrement 10
!
interface Port-channel1.19
description amari_it_office_vlan
encapsulation dot1Q 19
ip address 10.99.1.8 255.255.0.0
standby 3 ip 10.99.1.6
standby 3 priority 110
standby 3 preempt
standby 3 track 1 decrement 10
!
interface Port-channel1.20
description amari_st_vlan
encapsulation dot1Q 20
ip address 10.33.1.8 255.255.0.0
standby 2 ip 10.33.1.6
standby 2 priority 110
standby 2 preempt
standby 2 track 1 decrement 10
!
interface Port-channel1.99
description amari_bt_mgmt_vlan
encapsulation dot1Q 99
ip address 10.214.1.8 255.255.0.0
standby 4 ip 10.214.1.6
standby 4 priority 110
standby 4 preempt
standby 4 track 1 decrement 10
!
interface GigabitEthernet0/0
description ww_mgmt_access
ip address 172.200.200.2 255.255.255.0
!
!
interface GigabitEthernet0/1
description etherchannel_channel-port1_member
no ip address
channel-group 1
!
!
interface GigabitEthernet0/2
description etherchannel_channel-port1_member
no ip address
channel-group 1
!
ip route 0.0.0.0 0.0.0.0 10.200.0.1
!
router ospf 1
log-adjacency-changes
redistribute connected subnets
redistribute static subnets
passive-interface Port-channel1.19
passive-interface Port-channel1.20
passive-interface Port-channel1.99
!
!
!
HQ SW1-Cisco-2960-EtherChannel :

spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
vlan 10
name Amari_IT_Vlan
!
vlan 19
name Amari_IT_Office_Vlan
!
vlan 20
name Amari_ST_Vlan
!
vlan 99
name Amari_BT_mgmt
!
vlan 200
name Management
!
!
!
interface Loopback200
description WW_management
ip address 85.234.95.199 255.255.255.255
!
interface Port-channel1
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
!
interface Port-channel2
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
!
interface GigabitEthernet0/1
description Link_TO_Customer_Lan
switchport trunk allowed vlan 10,19,20,99
switchport mode trunk
!
!
interface GigabitEthernet0/19
description ww_mgmt
switchport access vlan 200
switchport mode access
speed 1000
duplex full
!
interface GigabitEthernet0/20
description Connected_To_amari_hq_lan_mpls_gw
switchport trunk allowed vlan 10,200
switchport mode trunk
speed 1000
duplex full
!
interface GigabitEthernet0/21
description PortChan_connected_amari_hq_lan_sw2
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet0/22
description PortChan_connected_amari_hq_lan_sw2
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet0/23
description PortChan_connected_amari_hq_lan_gw1
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
channel-group 2 mode on
!
interface GigabitEthernet0/24
description PortChan_connected_amari_hq_lan_gw1
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
channel-group 2 mode on
!
!
interface Vlan1
no ip address
no ip route-cache
!
interface Vlan200
ip address 172.200.200.4 255.255.255.0
ip access-group ww_mgmt in
!
ip default-gateway 172.200.200.6
!
!
!
HQ SW2-Cisco-2960-EtherChannel :
!
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
vlan 10
name Amari_IT_Vlan
!
vlan 19
name Amari_IT_Office_Vlan
!
vlan 20
name Amari_ST_Vlan
!
vlan 99
name Amari_BT_mgmt_Vlan
!
vlan 200
name Management_Vlan
!
!
!
interface Loopback12
no ip address
!
interface Loopback200
ip address 85.234.95.200 255.255.255.255
!
interface Port-channel1
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
!
interface Port-channel2
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
!
interface GigabitEthernet0/1
description Link_to_Customer_Lan
switchport trunk allowed vlan 10,19,20,99
switchport mode trunk
!
interface GigabitEthernet0/19
description ww_mgmt
switchport access vlan 200
switchport mode access
speed 1000
duplex full
!
interface GigabitEthernet0/20
description Link_To_amari_hq_lan_mpls_gw
switchport trunk allowed vlan 10,200
switchport mode trunk
speed 1000
duplex full
!
interface GigabitEthernet0/21
description PortChan_Connected_amari_hq_lan_sw1
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet0/22
description PortChan_Connected_amari_hq_lan_sw1
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet0/23
description PortCh_connected_amari_hq_lan_gw2
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
channel-group 2 mode on
!
interface GigabitEthernet0/24
description PortCh_connected_amari_hq_lan_gw2
switchport trunk allowed vlan 10,19,20,99,200
switchport mode trunk
channel-group 2 mode on
!
interface Vlan1
no ip address
no ip route-cache
!
interface Vlan200
ip address 172.200.200.5 255.255.255.0
ip access-group ww_mgmt in
!
ip default-gateway 172.200.200.6

Cisco IOS SSL VPN Example

The IOS SSL VPN features are definitely lagging behind the ASA SSL VPN, but the basic functionality
is available within
IOS SSL VPN. The IOS SSL VPN supports clientless, thin client, and full client modes.
The clientless mode uses a web portal. Thin client augments the web portal with port forwarding
capability. The
full client uses the AnyConnect SSL client.

The IOS SSL VPN does not have RDP, telnet, ssh, etc plugin capability that exists in the ASA SSL VPN.
It also does not support the dynamic access policy(DAP) also available in the ASA SSL VPN.

For this example, the router needs to provide a users network secure access to
R1 through an
SSL web portal. HTTP acccess, to R1, is provided through a URL link.
HTTPS and SSH access, to R1, is provided by port forwarding.

In a real world example
, this type of access could allow emergency access for a network
administrator from any computer.
********************

The first step is to set up the authentication method for the user. The IOS SSL VPN uses the
default AAA method by default.

For this example, we will use local authentication with the commands below :

aaa new-model
aaa authentication login default local
username cisco password cisco

********************
!
!
The next step is to setup the IP and port information for connectivity to the SSL VPN.
The IOS SSL VPN allows the IP to be based on the interface IP of the router or a virtual IP address.
Additionally, the port can be the standard 443/tcp or it can be another manually assigned port.
For this example, we will use the fa1/0 interface of the router and port 8000/tcp.

This is shown below :

webvpn gateway SSL1
hostname SSL1
ip address 192.168.137.100 port 8000
ssl trustpoint TP-self-signed-4294967295
inservice

Notice the “ssl trustpoint” in the configuration.
This is automatically created when the “inservice” command is added to active the configuration.
********************
!
!
The next step is to create the “webvpn context“.
As stated earlier, this is the container for the VPN parameters.
Within the “webvpn context” container, there are number of parameters that are defined and applied.
!
For example
:

  1. A URL can be defined
  2. The URL can be applied to a policy group
  3. The policy group can then be applied to the context

This is all within the “webvpn context” container.

An example is shown below :

webvpn context SSL
url-list “R1”
heading “R1”
url-text “R1-http” url-value “http://192.168.1.2”
policy group default
url-list “R1”
default-group-policy default

This shows the URL list, R1, being defined and then applied to the policy group, default.
The policy group, default, is then applied to the context with the “default-group-policy” command.
********************
!
!
In a similar manner, the IOS SSL VPN can support port forwarding.
This is shown below :

webvpn context SSL
port-forward “R1”
local-port 5000 remote-server “192.168.1.2” remote-port 443 description “R1 HTTPS”
local-port 5001 remote-server “192.168.1.2” remote-port 22 description “R1 SSH”

policy group default
port-forward “R1” auto-download
default-group-policy default

This portion shows how to forward ports.
When a user uses a web browser to access https://127.0.0.1:5000,
they are redirected to https://192.168.1.2 through the SSL connection.
Similarly, when a users uses an
SSH client to access 127.0.0.1 on port 5001, they are redirected to 192.168.1.2 on port 22.
********************
In the “port-forward” command, notice the “auto-download” parameter.
This causes the port forward connectivity to launch automatically,
instead of requiring the user to click on the “thin client” start button shown below :

The screenshots below show the GUI experience based on the configuration above.
1. The user accesses the web portal at https://192.168.137.100:8000

2. The user logs in and is presented with the web portal

3. At the same time as step 2, the port forwarding window appears with the setting for port forwarding

Below is the full relevant config for the example above :

aaa new-model
!
!
aaa authentication login default local
username cisco password 0 cisco
no ip http server
no ip http secure-server
webvpn gateway SSL1
hostname SSL1
ip address 192.168.137.100 port 8000
ssl trustpoint TP-self-signed-4294967295
inservice
!
webvpn context SSL
ssl authenticate verify all
!
url-list “R1”
heading “R1”
url-text “R1-http” url-value “http://192.168.1.2”
!
!
port-forward “R1”
local-port 5000 remote-server “192.168.1.2” remote-port 443 description “R1 HTTPS”
local-port 5001 remote-server “192.168.1.2” remote-port 22 description “R1 SSH”
!
policy group default
url-list “R1”
port-forward “R1” auto-download
banner “Welcome to the IOS SSL Lab”
default-group-policy default
gateway SSL1
inservice

Load Balancing with Cisco CSS 11000 and WebSphere Portal V5

Introduction

IBM® WebSphere® Portal V5 provides an environment to build and deploy sophisticated
Web-based applications, called portals. A portal is a Web site that provides users with a single point
of access to Web resources. As e-businesses grow, they roll out more advanced Web applications to a
wider audience. The e-business portal becomes another “face” of the company that serves its customers;
therefore, it is important for the portal to be available and to provide reasonable response times
.

The CSS 11000 is designed for HTTP traffic optimization. The switch software adds a Web-based layer to
the switching mechanism. Requests are parsed so that intelligent decisions can be made using information
in
IP frames, URLs, and cookies.
CSS 11000/Portal Server Network

Requests coming into the CSS 11000 are distributed across a group of portal servers.
As demand grows, you might decide to add more servers. Because a single portal page is constructed from
many
HTTP requests, each portal server can assume part of the load, reducing the page response time.
Also, if one of the portal servers fails, requests can be routed to another server in the group.

Setting up Cisco CSS 11000

When creating a load balancing configuration, you must configure services and content rules.
Services identify the actual individual server, and content rules define the CSS load balancing features.

Configuring services

Create a service for each WebSEAL host and set the keepalive type to http.
With http keepalive, CSS generates an HTTP request and checks the response to see if the service is
still active
. If CSS determines that a service is no longer functioning, it removes the service from the
load balancing algorithm
.

Listing 1. Configuring services with keepalive

************************** SERVICE **************************
service WPST01
ip address 192.168.120.61
keepalive type HTTP
active

service WPST02
ip address 192.168.120.63
keepalive type HTTP
active

service WPST03
ip address 192.168.120.65
keepalive type HTTP
activeservice WPST03

Sepcifying content rules

All content rules must exist under an owner. To specify the content rule to match all TCP traffic
on port 80, as shown in listing 2:

1. Set the protocol to be TCP.
2. Set the TCP port to be 80.
3. Add services to content rule to create pool of servers CSS uses for load balancing request for content.
4. Create a virtual IP address for the content rule. Customers use this address to access portal resources.

Listing 2. Content Rules

*************************** OWNER ***************************
owner IBM
content PORTAL
protocol tcp
port 80
add service WPST01
add service WPST02
add service WPST03

vip address 192.168.120.50
active

Advanced load balancing

If your portal application requires that all requests be handled by the same server, you must enable
advanced load balancing for the content rule. The arrowpoint-cookie method enables the content rule to
associate the client to a server based on the unique service identifier of the selected server.
Use the string command to add a service identifier for each service.
Then add the advance-balance command with the arrowpoint-cookie option to the content rule definition.

In Listing 3, the bold text enables advanced load balancing.
Listing 3. Content rule with advanced balancing

************************** SERVICE **************************
service WPST01
ip address 192.168.120.61
keepalive type HTTP
string WPST01
active

service WPST02
ip address 192.168.120.63
keepalive type HTTP
string WPST02

active


service WPST03

ip address 192.168.120.65
keepalive type HTTP
string WPST03

active

*************************** OWNER ***************************
owner IBM
content PORTAL
protocol tcp
port 80
add service WPST01
add service WPST02
add service WPST03
vip address 192.168.120.50
advanced-balance arrowpoint-cookie
active


Conclusion

To have an effective On Demand business, you must be able to adjust quickly to changing conditions.
The combination of the Cisco CSS 11000 and the WebSphere Portal cluster gives portal administrators the
flexibility to easily add additional servers as customer demand increases.

Linksys WRT54GL UseMyNet

WiFi

Many Internet Cafe businesses want to offer WiFi access for customers with laptops.
Here the client-server software is not suitable as it is impractical to install the client software on each
customers laptop. In these circumstances the solution is to use  “captive portal” software.
This software runs on a PC or WiFi router and can intercept the traffic from the laptop and redirect it to
a “landing page” where the customer is asked for payment or authentication
.

Typically the software works as follows:

1.  Customer connects to the WiFi network of the Internet Cafe.
2. Customer launches web browser and enters desired site (for example www.indiatimes.com).
3. Customer is redirected to the “landing page” instead of the desired site.
4. Customer is prompted for and enters access code.
5. Customer’s laptop is authenticated for the session time.
6. Customer’s web browser is redirect to desired site (for example www.indiatimes.com).

Inter LAN connectivity is disabled. Host on the Lan will not be allowed to connect to another
host on the Lan. Is is the security measure in place since these devices using UseMyNet software
are more likely to be used in public places
. Data Protection is enforced here.

In order to allow internal Lan Connectivity :

Traffic to local networks are blocked by default as most customers require this.
You can edit the file
/etc/init.d/umn and remove any or all of the following 3 lines

iptables -A FORWARD -i $LAN -d 10.0.0.0/8 -J REJECT –reject-with icmp-host-prohibited
iptables -A FORWARD -i $LAN -d 172.16.0.0/12 -J REJECT –reject-with icmp-host-prohibited
iptables -A FORWARD -i $LAN -d 192.168.0.0/16 -J REJECT –reject-with icmp-host-prohibited

How IPSec Works

How IPSec Works

IPSec involves many component technologies and encryption methods.
Yet IPSec’s operation can be broken down into five main steps:

  1. “Interesting traffic” initiates the IPSec process. Traffic is deemed interesting when the IPSec
    security policy configured in the IPSec peers starts the IKE process.
  2. IKE phase 1. IKE authenticates IPSec peers and negotiates IKE SAs during this phase,
    setting up a secure channel for negotiating IPSec SAs in phase 2.
  3. IKE phase 2. IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers.
  4. Data transfer. Data is transferred between IPSec peers based on the IPSec parameters and
    keys stored in the SA database.
  5. IPSec tunnel termination. IPSec SAs terminate through deletion or by timing out.

This five-step process :

The five steps of IPSec for dummies like Mufty:

Step 1—Defining Interesting Traffic

What type of traffic is deemed interesting is determined as part of formulating a security
policy for use of a VPN. The policy is then implemented in the configuration interface for
each particular IPSec peer.

For example, in Cisco routers and PIX Firewalls, access lists are used to determine the
traffic to encrypt. The access lists are assigned to a cryptography policy;
the policy’s
permit statements indicate that the selected traffic must be encrypted, and deny statements
indicate that the selected traffic must be sent unencrypted
. With the Cisco Secure VPN Client, you
use menu windows to select connections to be secured by IPSec. When interesting traffic is generated
or transits the IPSec client, the client initiates the next step in the process
,
negotiating an IKE phase 1 exchange.

Defining “interesting traffic.”

Step 2—IKE Phase 1

The basic purpose of IKE phase 1 is to authenticate the IPSec peers and to set up a secure channel
between the peers to enable IKE exchanges. IKE phase 1 performs the following functions:

  • Authenticates and protects the identities of the IPSec peers
  • Negotiates a matching IKE SA policy between peers to protect the IKE exchange
  • Performs an authenticated Diffie-Hellman exchange with the end result of having matching
    shared secret keys
  • Sets up a secure tunnel to negotiate IKE phase 2 parameters

IKE phase 1 occurs in two modes: main mode and aggressive mode.
These modes are described in the following sections.

Main Mode

Main mode has three two-way exchanges between the initiator and the receiver.

  • First exchange: The algorithms and hashes used to secure the IKE communications are
    agreed upon in matching IKE SAs in each peer.
  • Second exchange: Uses a Diffie-Hellman exchange to generate shared secret keying material
    used to generate shared secret keys and to pass nonces—random numbers sent to the other
    party and then signed and returned to prove their identity.
  • Third exchange: Verifies the other side’s identity. The identity value is the IPSec peer’s IP address
    in encrypted form. The main outcome of main mode is matching IKE SAs between peers to provide
    a protected pipe for subsequent protected ISAKMP exchanges between the IKE peers.
    The IKE SA specifies values for the IKE exchange: the authentication method used, the encryption
    and hash algorithms, the Diffie-Hellman group used, the lifetime of the IKE SA in seconds or kilobytes,
    and the shared secret key values for the encryption algorithms.
    The IKE SA in each peer is bi-directional
    .

Aggressive Mode

In aggressive mode, fewer exchanges are made, and with fewer packets. On the first exchange,
almost everything is squeezed into the proposed IKE SA values: the Diffie-Hellman public key;
a nonce that the other party signs; and an identity packet, which can be used to verify identity
via a third party.

The receiver sends everything back that is needed to complete the exchange. The only thing left is
for the initiator to confirm the exchange. The weakness of using the aggressive mode is that both sides
have exchanged information before there’s a secure channel. Therefore, it’s possible to “sniff” the wire and
discover who formed the new SA. However,
it is faster than main mode.

Step 3—IKE Phase 2

The purpose of IKE phase 2 is to negotiate IPSec SAs to set up the IPSec tunnel.
IKE phase 2 performs the following functions:

  • Negotiates IPSec SA parameters protected by an existing IKE SA
  • Establishes IPSec security associations
  • Periodically renegotiates IPSec SAs to ensure security
  • Optionally performs an additional Diffie-Hellman exchange

IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the
secure tunnel in phase 1. It negotiates a shared IPSec policy, derives shared secret keying material
used for the IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces
that provide replay protection. The nonces are used to generate new shared secret key material and
prevent replay attacks from generating bogus SAs.

Quick mode is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires.
Base quick mode is used to refresh the keying material used to create the shared secret key based on the
keying material derived from the Diffie-Hellman exchange in phase 1.

Perfect Forward Secrecy

If perfect forward secrecy (PFS) is specified in the IPSec policy, a new Diffie-Hellman
exchange is performed with each quick mode, providing keying material that has
greater entropy (key material life) and thereby greater resistance to cryptographic attacks.
Each Diffie-Hellman exchange requires large exponentiations, thereby increasing CPU use
and exacting a performance cost.

Step 4—IPSec Encrypted Tunnel

After IKE phase 2 is complete and quick mode has established IPSec SAs, information is exchanged via
an IPSec tunnel. Packets are encrypted and decrypted using the encryption specified in the IPSec SA
.

IPSec encrypted tunnel.

Step 5—Tunnel Termination

IPSec SAs terminate through deletion or by timing out. An SA can time out when a
specified number of seconds have elapsed or when a specified number of bytes have passed through
the tunnel. When the SAs terminate, the keys are also discarded. When subsequent IPSec SAs are
needed for a flow, IKE performs a new phase 2 and, if necessary, a new phase 1 negotiation.
A successful negotiation results in new SAs and new keys. New SAs can be established before the
existing SAs expire, so that a given flow can continue uninterrupted.

Cisco Disable Password Recovery

There are times when you may want to disable password recovery
(for example if someone is working in high secure environment).

Use the following command to disable password recovery

Router(config)#no service password-recovery

   WARNING:
   Executing this command will disable password recovery mechanism.
   Do not execute this command without another plan for
   password recovery.

Are you sure you want to continue? [yes/no]: yes
Router(config)#

The above command will disable all access to the ROMMON.
Be careful when using the above command, as there is no way to recover password.

The following message is displayed during boot up when “no service password-recovery”
command is configured.

    PASSWORD RECOVERY FUNCTIONALITY IS DISABLED

    System Bootstrap, Version 11.1(19)AA, EARLY DEPLOYMENT RELEASE SOFTWARE
    (fc1)

…


Cisco IOS Zone-Based Firewall

The IOS Zone-Based Firewall first showed up in 12.4(6)T and the goal was to provide an intuitive
and straightforward policy design approach for multiple interface routers. There was also a desire
to offer a greater level of granularity for the application of such policies. The Zone-Based approach
utilizes
CBAC technology and gives you everything you had there, plus more.

In order to configure the Zone-Based Firewall, you define your zones, define your class maps,
define your policy maps, and then define your zone pairs and apply your policy maps to them.
Possible actions for traffic moving between zones is INSPECT, DROP, or PASS. Zone Drop or Pass?

Inspect causes the traffic to be monitored with the IOS stateful packet inspection (think CBAC),
while drop and pass are obvious.
Pass allows the traffic to move between zones with no inspection whatsoever
.

Step 1: Define and populate our zones:

configure terminal
!
zone security ZONE_PRIVATE
zone security ZONE_INTERNET

!
interface range fa0/0
description LAN
zone-member security ZONE_PRIVATE
!
interface s0/0
description WAN
zone-member security ZONE_INTERNET

Step 2: Define the class maps that identify traffic that is
permitted between zones
:

configure terminal
!
class-map type inspect match-any INTERNET_TRAFFIC
match protocol http
match protocol https
match protocol ftp
match protocol smtp
match protocol pop3
match protocol dns
match protocol ssh
match protocol icmp
match protocol cifs
match protocol echo
match protocol ntp
match protocol bittorrent
match protocol bootpc
match protocol bootps
match protocol rtsp
match protocol vdolive

Step 3: Configure a policy map which specifies the action for the
class map
:

configure terminal
!
policy-map type inspect PRIVATE_TO_INTERNET
class type inspect INTERNET_TRAFFIC
inspect

Step 4: Configure the zone pair and apply your policy:

configure terminal
!
zone-pair security ZONE_PRIVATE_INT source ZONE_PRIVATE destination ZONE_INTERNET
service-policy type inspect PRIVATE_TO_INTERNET

Notice how this simple configuration allows for the stateful inspection of our
Internet protocols from the private areas to the  Internet.
It also blocks traffic from the Internet heading to the private area unless it is
in response to the inspected traffic

My Configuration in Place :

ip inspect max-incomplete high 900
ip inspect max-incomplete low 800
ip inspect one-minute high 900
ip inspect one-minute low 800
ip inspect udp idle-time 15
ip inspect dns-timeout 10
ip inspect tcp idle-time 900

!
!
zone security inside_zone
zone security outside_zone
zone security dmz_zone
zone security multimedia_zone
zone security voip_zone
zone security peripheral_zone

!
!
class-map type inspect match-any IN_OUT
match protocol http
match protocol https
match protocol ftp
match protocol smtp
match protocol pop3
match protocol bootpc

match protocol bootps
match protocol icmp
match protocol msnmsgr
match protocol ntp

match protocol ssh
match protocol telnet
match protocol cifs
match protocol dns
match protocol tcp
match access-group name WORKSTATION_NAT
match access-group name PC-techAPDMZ_NAT

!
policy-map type inspect IN_OUT
class type inspect IN_OUT
inspect
class class-default
drop

!
zone-pair security IN->OUT source inside_zone destination outside_zone
service-policy type inspect IN_OUT

!
!
class-map type inspect match-any VOIP_OUT
match protocol udp
match access-group name VOIP_NAT

!
policy-map type inspect VOIP_OUT
class type inspect VOIP_OUT
inspect
class class-default
drop

!
zone-pair security VOIP->OUT source voip_zone destination outside_zone
service-policy type inspect VOIP_OUT

!
!
class-map type inspect match-any DMZ_OUT
match protocol http
match protocol https
match protocol ftp
match access-group name DMZ_NAT

!
policy-map type inspect DMZ_OUT
class type inspect DMZ_OUT
inspect
class class-default
drop

!
zone-pair security DMZ->OUT source dmz_zone destination outside_zone
service-policy type inspect DMZ_OUT

!
!
class-map type inspect match-any MULTIMEDIA_OUT
match protocol bittorrent
match protocol http
match protocol https
match protocol ftp
match protocol echo
match protocol smtp
match protocol pop3

match protocol icmp
match protocol pptp
match protocol tcp
match protocol udp
match access-group name MULTIMEDIA_NAT

!
policy-map type inspect MULTIMEDIA_OUT
class type inspect MULTIMEDIA_OUT
inspect
class class-default
drop

!
zone-pair security MULTIMEDIA->OUT source multimedia_zone destination outside_zone
service-policy type inspect MULTIMEDIA_OUT

!
!
class-map type inspect match-any IN_MULTIMEDIA
match protocol cifs
match protocol tcp
match access-group name WORKSTATION_NAT

!
policy-map type inspect IN_MULTIMEDIA
class type inspect IN_MULTIMEDIA
inspect
class class-default
drop

!
zone-pair security IN->MULTIMEDIA source inside_zone destination multimedia_zone
service-policy type inspect IN_MULTIMEDIA

!
!
class-map type inspect match-any IN_PERIPHERAL
match protocol tcp
!
policy-map type inspect IN_PERIPHERAL
class type inspect IN_PERIPHERAL
inspect
class class-default
drop

!
zone-pair security IN->PERIPHERAL source inside_zone destination peripheral_zone
service-policy type inspect IN_PERIPHERAL

!
!
class-map type inspect match-any PERIPHERAL_IN
match protocol tcp
match access-group name PERIPHERAL_INSPECT

!
policy-map type inspect PERIPHERAL_IN
class type inspect PERIPHERAL_IN
inspect
class class-default
drop

!
zone-pair security PERIPHERAL->IN source peripheral_zone destination inside_zone
service-policy type inspect PERIPHERAL_IN

!
!
Interface fa0/1.3
Zone-member security inside_zone
!
Interface fa0/1.4
Zone-member security inside_zone
!
Interface vlan 2
Zone-member security multimedia_zone
!
Interface vlan 10
Zone-member security dmz_zone
!
Interface fa0/0
Zone-member security outside_zone

Troubleshooting :

show policy-map type inspect zone-pair sessions
clear zone-pair inspect session policy-map MULTIMEDIA_OUT

Cisco qos pre-classify command

The point of the qos pre-classify command is to be able to read and manipulate the IP header
of a packet going through a
VPN.

The problem is that when a packet enters a VPN it is encrypted, header and all.
After this command is applied, the router makes a copy of the original IP header so that you can
perform
QoS manipulation at egress on an interface.

Actually if the ToS byte (DSCP, ECN or IP Precedence) is the only portion of the header that needs
manipulation. You don’t need qos pre-qualify, however, if you need access to source or destination
ip address or port numbers, then you need the
qos pre-qualify command.

Packets entering a router interface, not yet in a VPN tunnel, can be processed with
ingress QoS features on that interface just like always.
Packets exiting a router interface, after encapsulation and encryption by that router into a
VPN tunnel, cannot be processed with egress QoS features on that interface just like always
.

The Egress QoS features can only examine the post-encapsulation IP header.

That is why qos pre-classify makes a copy of the original IP header.
The command qos pre-classify turns on pre-classification and is restricted to
tunnel interfaces, virtual templates, and crypto maps
,
it is not available on any other interface type.

Apply the policy to a physical interface and enable qos-preclassify on a tunnel interface
when you want to classify packets based on the pre-tunnel header
.

Cisco recommends Preclassify over simple ToS Preservation anytime you want to match on
the
ToS byte only, or the ToS byte and other parameters like Source and Destination ports,

Preclassify is always recommended in Security/QoS environments.

QoS for VPNs feature. This feature is enabled with the qos pre-classify.
Remember that a packet is encrypted in the vpn process, so the pre-clasify will mark the packets
so they can apply the service policy and prioritise voice,video or whatever traffic
.

I performed a packet capture, and, as expected, i only see :
ESP packets with the DSCP value set at 0.

Place qos pre-classify command in the crypto map.

crypto map vpn 10 ipsec-isakmp
qos pre-classify

These are the guidelines for implementing QoS :

  • Classify and mark as close to the source as possible.
  • Police traffic as close to the source as possible.
  • Establish proper trust boundaries.
  • Classify and mark real-time voice and video as high-priority traffic.
  • Use multiple queues on transmit interfaces.
  • Try to perform hardware-based rather software-based QoS.

Control Plane Policing

The control plane of a Cisco router includes the data plane, management plane and service plane.
Control plane policing allows you to build QoS filters to protect the router against DoS attacks.

Cisco Linux 2 Site-to-Site Ipsec VPN

2 sites Cisco routers terminating vpn on a linux firewall.
See configuration of 2 cisco router as well as linux firewall
.
!
!
HQ advertising 2 internal networks :

128.0.0.0/16
10.0.0.0/16

Remote site advertising 1 internal network :

128.0.0.0/16

Cisco HQ IPSEC VPN Config :

crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key ahdbpr0t3ct address 80.74.16.223
!
crypto ipsec transform-set secure esp-3des esp-md5-hmac
!
crypto map armadillo 1 ipsec-isakmp
set peer 80.74.16.223
set transform-set secure
match address 101
!
crypto map armadillo 2 ipsec-isakmp
set peer 80.74.16.223
set security-association lifetime seconds 28800
set security-association idle-time 86400
set transform-set secure
match address 102
!
access-list 101 permit ip 128.0.0.0 0.0.255.255 128.0.0.0 0.255.255.255
access-list 102 permit ip 10.0.0.0 0.0.255.255 128.10.0.0 0.0.255.255

!
interface FastEthernet0/0
description WAN-Interface
ip address 213.121.189.250 255.255.255.0
crypto map armadillo
!
interface vlan 1
description MLC vlan
ip address 128.0.15.250 255.255.0.0
!
interface vlan 2
description AHDB vlan
ip address 10.0.15.1 255.255.0.0
!
!
Cisco RemoteSite IPSEC VPN Config :

crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key ahdbpr0t3ct address 80.74.16.223
!
!
crypto ipsec transform-set secure esp-3des esp-md5-hmac
!
crypto map securewan 1 ipsec-isakmp
set peer 80.74.16.223
set security-association lifetime seconds 28800
set security-association idle-time 86400
set transform-set secure
match address VPN
!

ip access-list extended VPN
permit ip 128.10.0.0 0.0.255.255 128.0.0.0 0.0.255.255
permit ip 128.10.0.0 0.0.255.255 10.0.0.0 0.0.255.255

!
interface Dialer0
ip address 80.74.22.136 255.255.255.0
crypto map securewan
!
!

Linux Firewall Configuration :
Directory path of ipsec conf file ( /etc/ipsec/site name)
!
HQ Network : 128.0.0.0/16 & 10.0.0.0/16
!
128.0.0.0/16 to HQ 128.0.0.0/16
10.0.0.0/16 to HQ 128.0.0.0/16

conn HQ1
left=80.74.16.223
leftsubnet=128.0.0.0/16
right=213.121.189.250
rightsubnet=128.0.0.0/16
type=tunnel
authby=secret
auth=esp
esp=3des-md5-96
keyexchange=ike
ikelifetime=24h
keylife=28800s
keyingtries=3
pfs=no
rekey=yes
auto=start
dpdaction=restart
dpddelay=15
dpdtimeout=60
!
conn HQ2
left=80.74.16.223
leftsubnet=128.10.0.0/16
right=213.121.189.250
rightsubnet=10.0.0.0/16
type=tunnel
authby=secret
auth=esp
esp=3des-md5-96
keyexchange=ike
ikelifetime=24h
keylife=28800s
keyingtries=3
pfs=no
rekey=yes
auto=start
dpdaction=restart
dpddelay=15
dpdtimeout=60
!
!
RemoteSite Network : Access to HQ Network :
128.0.0.0/16 to HQ 128.0.0.0/16
128.0.0.0/16 to HQ 10.0.0.0/16

conn remotesite1
left=80.74.16.223
leftsubnet=128.0.0.0/16
right=80.74.22.136
rightsubnet=128.10.0.0/16
type=tunnel
authby=secret
auth=esp
esp=3des-md5-96
keyexchange=ike
ikelifetime=24h
keylife=28800s
keyingtries=3
pfs=no
rekey=no
auto=start
dpdaction=restart
dpddelay=15
dpdtimeout=60
!
conn remotesite2
left=80.74.16.223
leftsubnet=10.0.0.0/16
right=80.74.22.136
rightsubnet=128.10.0.0/16
type=tunnel
authby=secret
auth=esp
esp=3des-md5-96
keyexchange=ike
ikelifetime=24h
keylife=28800s
keyingtries=3
pfs=no
rekey=yes
auto=start
dpdaction=restart
dpddelay=15
dpdtimeout=60

Configure Linux Firewall Iptables to forward traffic from RemoteSite over to HQ.

sudo iptables -I FORWARD -s 128.0.0.0/16 -d 128.0.0.0/16 -j ACCEPT
sudo iptables -I FORWARD -s 128.0.0.0/16 -d 10.0.0.0/16 -j ACCEPT

Configure Linux Firewall Iptables to forward traffic from HQ to RemoteSite.

sudo iptables -I FORWARD -s 128.0.0.0/16 -d 128.0.0.0/16 -j ACCEPT
this one is configured in a previous rule as above.
!
sudo iptables -I FORWARD -s 10.0.0.0/16 -d 128.0.0.0/16 -j ACCEPT

Cisco Time-Range QOS

This output shows an example of creating a time-based named ACL.
It denies HTTP traffic on Monday through Friday between the hours of 8:00 am and 6:00 pm
and allows UDP traffic on Saturday and Sunday from noon to 8:00 pm.

!
time-range no-http
periodic weekdays 8:00 to 18:00
!
time-range udp-yes
periodic weekend 12:00 to 20:00
!
ip access-list extended strict
permit tcp any any eq http time-range no-http
permit udp any any time-range udp-yes
!
!
Keep in mind there is an explicit deny at the end of the ACL. If you are going to permit ip any any
at the bottom of ACL, keep in mind that there has to be a deny entry for tcp HTTP traffic. This is because
when time-range no http ACL is in inactive state, it looks for a matching rule that will either permit or deny HTTP traffic
.
!
Example of using a time-based ACL in QoS Policy:
!
class-map Traffic_Class
match access-group strict
!
policy-map QoS-Policy
class Traffic_Class
priority 500
class class-default
fair-queue