Router: Debug Crypto Condition command

When your router has more than one vpn peer configured, troubleshooting one of the problematic crypto peer using debug crypto isakmp and debug crypto ipsec can get you crosseyed in no time. You'll feel like the console is doing a DOS on your brain.

In Cisco IOS Software Release 12.3(2)T, you can use the debug crypto condition command to filter debug output to a specific peer. You can use many criteria to customize the output, including peer IP, SPI, connid, flowid, etc. This filter causes the router to show only the crypto messages for the peer you are troubleshooting.

For example, first define a condition with a peer IP before enabling debug crypto:
debug crypto condition peer ipv4 2.2.2.2
debug crypto isakmp
debug crypto isakmp packet <---helpful hidden command debug crypto ipsec
To identify which debug conditions are active:
sh crypto debug-condition

Lab: RTBH

This is something I setup in my desktop lab (Dynamips) based on the REMOTELY TRIGGERED BLACK HOLE FILTERING—DESTINATION BASED AND SOURCE BASED white paper available from Cisco website.

Configurations
Target
Edge
Trigger
RR-BGP
PE1
PE2
Smurf

In the diagram, the provider network is enclosed in the blue area. The Target router is the victim and Smurf is the attacker network. Let's say we're seeing massive amount of traffic coming from Smurf network with destination as the Target router. We identify these as a dos attack on the Target network so as Service Provider we must: 1. Protect our customer and 2. Protect the provider network.
RTBH provides a method of telling the provider edge routers to block an identified traffic just by adding the source or destination address to a sort of blacklist. These blacklist are actually static routes added to the Trigger router that are propagated throughout the network via iBGP. These routes points to a null interface as its next-hop, so effectively dropping the bogus traffic.

Lab: Integrated DMVPN and EZVPN with IPSec Stateful Failover

Here's something I setup in my desktop "lab" using DYNAMIPS. I created two DMVPN hubs also acting as a EZVPN server with Stateful Failover. Since both DMVPN and EZVPN configuration is using 0.0.0.0 address to map to the pre-shared key, a ISAKMP Profile is configured to differentiate the DMVPN spokes and the EZVPN clients.

Previously, if your router talk to a combination of remote spokes and vpn client (software or ezvpn remote) that have dynamic ip addresses, your only option is to use certificates for your IKE authentication. If you use pre-shared keys, you cannot distinguish which IKE peers should have extended authentication and which one should not use it. Well that was before ISAKMP Profile was available. ISAKMP Profile should be used for any router with two or more IPSec connections that requires different phase 1 parameters for different sites (for example, configuring site-to-site and remote access on the same router). You can configure to authenticate one peer using certificates while another peer is authenticated using pre-shared keys.

Here are the configs.
Hub1 Configuration
Hub2 Configuration
EZVPN Remote Client Configuration
DMVPN Spoke1 Configuration
DMVPN Spoke2 Configuration

You can refer to Cisco's Deployment Guide for more detailed info.

Router: Zone-based Firewalls part III

Now let's look at an example where we have three zones: inside, outside and dmz. There are servers in the DMZ zone that needs to be accessible from the inside and outside network. We will restrict Outside to DMZ traffic only to ip 192.1.1.1 via http.

! we define the zones
!
 zone security Inside
 zone security Outside
 zone security DMZ
!
! we apply the zones to the interfaces
!
interface FastEthernet0/0
 ...
 zone-member security Inside
!
interface FastEthernet0/1
 ...
 zone-member security DMZ
!
interface Serial0/0.100 point-to-point
 description Link to the Internet
 ...
 zone-member security Outside
!
! Match any traffic going to the Webserver
!
access-list 199 permit ip any host 192.1.1.1
!
! match traffic to be inspected
!
class-map type inspect insp-traffic
 match protocol http
 match protocol icmp
 match protocol tcp
!
! match http traffic going to the webserver
!
class-map type inspect match-all http_traffic
 match access-group 199
 match protocol http
!
class-map type inspect match-all toDMZfromInside
 match access-group 199
 match class-map insp-traffic
!
class-map type inspect match-any DNS
 match protocol dns
!
policy-map type inspect out_traffic
 class type inspect insp-traffic
  inspect
!
policy-map type inspect toDMZfromInsideTraffic
 class type inspect toDMZfromInside
  inspect
!
policy-map type inspect webtraffic
 class type inspect http_traffic
  inspect
!
policy-map type inspect DNSTraffic
 class type inspect DNS
  inspect
!
! security policy for inside to outside traffic
!
zone-pair security InsideToOutside source Inside destination Outside
service-policy type inspect out_traffic
!
! security policy for outside to dmz traffic
!
zone-pair security OutsideToDMZ source Outside destination DMZ
service-policy type inspect webtraffic
!
! security policy for inside to dmz traffic
!
zone-pair security InsideToDMZ source Inside destination DMZ
service-policy type inspect toDMZfromInsideTraffic
!
! security policy for dmz to outside traffic
!
zone-pair security DMZToOutside source DMZ destination Outside
service-policy type inspect DNSTraffic
!

Notice that there is no security policy for traffic going from Outside to Inside or from DMZ to Inside. This configuration will drop any traffic going to the Inside network.

Zone-based Firewall is modular making the configuration much more easier to read. You can add more zones or you can add more interfaces to each zone without cluttering the configuration and thus easing troubleshooting. It removes the firewall's dependency on access-lists and allows you to configure one policy for any given traffic.

For more info, check out Cisco documentation (of course!) and discussion slide on zone-based firewall and the excellent ebook Deploying Zone-Based Firewalls (Digital Short Cut) from Ivan Pepelnjak.

Router: Zone-based Firewalls part II

In the first installment of this document, I showed you a simple two-zone configuration where inside users have unrestricted access to the outside zone.

If you need to limit the services that the inside users are allowed to access, we have to define the traffic classes that will later be used in the policy-map commands to define the desired firewall policy. The traffic classes are defined with the class-map command augmented with the type inspect keyword.

!
! These are the Class maps to define
! the outgoing traffic that are permitted.
!
class-map type inspect match-any MailAndDNS
match protocol dns
match protocol smtp
match protocol pop3
class-map type inspect match-all ISP_Traffic
match class-map MailAndDNS
match access-group name ISPServers
class-map type inspect match-any InternetTraffic
match protocol http
match protocol ftp
match protocol icmp
match protocol https
!
!
policy-map type inspect InsideToOutside
!
! Action for defined class-map is inspect
!
class type inspect ISP_Traffic
 inspect
class type inspect InternetTraffic
 inspect
!
! Action for all other traffic are dropped and logged
!
class class-default
drop log
!
! we define the zones
!
zone security Inside
zone security Outside
!
! we define the security policy
!
zone-pair security InsideToOutside source Inside destination Outside
service-policy type inspect InsideToOutside
!
! we apply the zones to the interfaces
!
interface FastEthernet0/0
...
zone-member security Inside
!
interface Serial0/0.100 point-to-point
description Link to the Internet
...
zone-member security Outside
!
ip access-list extended ISPServers
permit ip any host 192.1.1.1
permit ip any host 192.1.1.2

This time we used the action drop and log for the class class-default.
With this configuration, outbound traffic are restricted to those services defined in the class-maps. Matching traffic are permitted and inspected while those that does not match are dropped. There is still no security policy defined for inbound traffic (outside-to-inside) so it will be dropped by the router.

Router: Zone-based Firewalls part I

A new configuration enhancement has been introduced in IOS 12.4(6)T called Zone-based policy firewall. Rather than configuring multiple access-lists to filter traffic between multiple router interfaces, you follow the zone-based design and only have to specify the traffic permitted between zones. Zone-based policy firewall also adds more granularity to inspection policies comapared to CBAC.

Here are some notes:

1. The zone-based policy firewall can coexist with Cisco IOS Firewall stateful inspection. You can still use the ip inspect command on interfaces that are not members of security zones.
   
2. Traffic can never flow between an interface assigned to a zone and an interface without a zone assignment.
   
3. The default interzone policy is to drop all traffic unless specified otherwise in the zone-pair configuration command.
   
4. The router never filters the traffic between interfaces in the same zone.
   
5. If two interfaces are not in zones, traffic flows freely between them.
   
6. The zone-member command does not protect the router itself (traffic to and from the router is not affected) unless you configure the zone pairs using the predefined self zone.
   

Examples are available on this slide.

Here's a simple example.

! Create the zones. for this example we only have two zones
!
zone security Inside
 description This is the Internal network

zone security Outside
 description This Internet zone
!
! Using policy-map, we specify the action to do
! on the traffic matching the class-maps
! For this example, we use the default class
! class-default = match all
!
policy-map type inspect InsideToOutside
 class class-default
 inspect
!
! Apply the policy to traffic between a pair of zones
!
 zone-pair security InsideToOutside source Inside destination Outside
 service-policy type inspect InsideToOutside
!
! Assign the interfaces to each zones
!
interface FastEthernet0/0
 zone-member security Inside
!
interface Serial0/0/0.100 point-to-point
 zone-member security outside

This is a simple two-zone configuration where a security policy is defined for outbound traffic (inside-to-outside). Inbound traffic will be dropped since there is no security policy defined for outside-to-inside traffic.

Router: Surfing without Split-tunnelling

Scenario: Users connect remotely via Cisco VPN client. They connect to your router. They need to access the Internet while logged-in but you don't want to configure split-tunnelling. You want the VPN client to access the internet thru the router and not by split-tunneling so that you can later enable url-filtering or use audit-trail to monitor their browsing activities.
Config:

username cisco password cisco123
aaa new-model
!
!
aaa authentication login userauthen local
aaa authorization network groupauthor local
!
crypto isakmp policy 3
encr 3des
authentication pre-share
group 2
!
crypto isakmp client configuration group RAS
key cisco123
domain cisco.com
pool ippool
!
!
crypto ipsec transform-set myset esp-3des esp-md5-hmac
!
crypto dynamic-map dynmap 10
set transform-set myset
!
!
crypto map clientmap client authentication list userauthen
crypto map clientmap isakmp authorization list groupauthor
crypto map clientmap client configuration address respond
crypto map clientmap 10 ipsec-isakmp dynamic dynmap
!
! User's traffic will be redirected to this loopback interface
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
ip nat inside
!
interface Ethernet0/1
ip address 192.168.20.1 255.255.255.0
ip nat inside
!
interface Ethernet0/0
...
ip nat outside
ip policy route-map redir

crypto map clientmap
!
ip local pool ippool 192.168.1.100 192.168.1.200
ip nat inside source list NAT interface Ethernet0/0 overload
!
ip access-list extended NAT
deny ip 192.168.20.0 0.0.0.255 192.168.1.0 0.0.0.255
permit ip 192.168.20.0 0.0.0.255 any
permit ip 192.168.1.0 0.0.0.255 any
!
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
!
! This route map redirects vpn client traffic to Loopback0
!
route-map redir permit 10
match ip address 101
set interface Loopback0



On the pix/asa, check this sample configuration from Cisco for a similar "vpn-on-a-stick" setup.