yurisk.info

Yuri Slobodyanyuk's blog on IT Security and Networking sharing experience and expertise

Page 12 of 24

sla monitor in Cisco ASA land

SLA monitoring is finally here. What is it useful for ? To add/remove dynamically routes in ASA depending on results of the SLA status.
Below is configuration steps but while there are many words in the command itself there are not much options there , so the command is long but pretty uniform.

TokyoASA1(config)# sla monitor 33
TokyoASA1(config-sla-monitor)# type echo protocol ipIcmpEcho 150.6.2.2 int outside type echo
TokyoASA1(config-sla-monitor-echo)# ?
default Set a command to its defaults
exit Exit probe configuration
frequency Frequency of an operation
no Negate a command or set its defaults
num-packets Number of Packets
request-data-size Request data size
threshold Operation threshold in milliseconds
timeout Timeout of an operation
tos Type Of Service
TokyoASA1(config-sla-monitor-echo)# frequency ?
sla-monitor-echo mode commands/options:
<1-604800> Frequency in seconds
TokyoASA1(config)# sla monitor schedule 33 ?
ageout How long to keep this Entry when inactive
life Length of time to execute in seconds
recurring Probe to be scheduled automatically every day
start-time When to start this entry
TokyoASA1(config)# sla monitor schedule 33 life forever start after 00:05:00

Now create tracking process to be later applied to the static route:

TokyoASA1(config)# track 1 rtr 33 reachability

And finally we create static route and attach to it the created track :

TokyoASA1(config)# route outside 0 0 136.6.123.3 track 1

Now let’s see some statistics on the track:

TokyoASA1# sh track
Track 1
Response Time Reporter 33 reachability
Reachability is Down
1 change, last change 00:04:03
Latest operation return code: Unknown
Tracked by:
STATIC-IP-ROUTING 0

The final configuration looks like

sla monitor 33
type echo protocol ipIcmpEcho 150.6.2.2 interface outside
num-packets 3
request-data-size 1500
timeout 30
frequency 5
sla monitor schedule 33 life forever start-time after 00:05:00
TokyoASA1# sh sla monitor configuration
SA Agent, Infrastructure Engine-II
Entry number: 33
Owner:
Tag:
Type of operation to perform: echo
Target address: 150.6.2.2
Interface: outside
Number of packets: 3
Request size (ARR data portion): 1500
Operation timeout (milliseconds): 30
Type Of Service parameters: 0x0
Verify data: No
Operation frequency (seconds): 5
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Enhanced History:
TokyoASA1# sh sla monitor configuration operational-state
Entry number: 33
Modification time: 15:14:04.168 UTC Sun May 23 2010
Number of Octets Used by this Entry: 1480
Number of operations attempted: 48
Number of operations skipped: 0
Current seconds left in Life: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Connection loss occurred: FALSE
Timeout occurred: FALSE
Over thresholds occurred: FALSE
Latest RTT (milliseconds): 1
Latest operation start time: 15:22:59.169 UTC Sun May 23 2010
Latest operation return code: OK
RTT Values:
RTTAvg: 1RTTMin: 1RTTMax: 1
NumOfRTT: 3RTTSum: 3RTTSum2: 3
TokyoASA1# debug sla monitor ?
error Output IP SLA Monitor Error Messages
trace Output IP SLA Monitor Trace Messages
TokyoASA1# debug sla monitor trace
TokyoASA1# IP SLA Monitor(33) Scheduler: Starting an operation
IP SLA Monitor(33) echo operation: Sending an echo operation
IP SLA Monitor(33) echo operation: RTT=0 OK
IP SLA Monitor(33) echo operation: RTT=0 OK
IP SLA Monitor(33) echo operation: RTT=1 OK
IP SLA Monitor(33) Scheduler: Updating result
IP SLA Monitor(33) Scheduler: Starting an operation
IP SLA Monitor(33) echo operation: Sending an echo operation
IP SLA Monitor(33) echo operation: RTT=0 OK
IP SLA Monitor(33) echo operation: RTT=0 OK
IP SLA Monitor(33) echo operation: RTT=1 OK

And by the way it really works – when track is down the route to which it is attached magically disappeared
from the routing table as should.

Teach ASA to speak NTP

Time is precious, even more when you need accurate logging to know when someone breaks into your systems. Let’s configure NTP time synchronization on our ASA 5510.
Configs are pretty simple, but worth remembering a thing or two.

  • ASA can not be NTP server as opposed to IOS.
  • You can use prefer optional keyword with ntp server command but … it works if you have multiple servers having “the same accuracy” by Cisco.com words. In people’s language they mean the same stratum. If your ASA has 2 servers – one of stratum 2 and other of stratum 3 , even if you put stratum 3 server as preferred the one of stratum 2 will be selected.
  • Authentication is available but oprional. The only algorithm of choice is MD5.
  • You can have multiple trusted keys at the same time, I guess they will be tried in turn (needs verification).

Ok then, back to CLI – NTP server is 153.6.3.3, use authentication, MD5.

TokyoASA1(config)# ntp authentication-key 1 md5 CISCO
TokyoASA1(config)# ntp trusted-key 1
TokyoASA1(config)# ntp server 153.6.3.3 ?
key Configure peer authentication key
prefer Prefer this peer when possible
source Interface for source address
<cr>
TokyoASA1(config)# ntp server 153.6.3.3 key 1
TokyoASA1(config)# ntp authenticate
TokyoASA1# debug ntp ?
adjust NTP clock adjustments
authentication NTP authentication
events NTP events
loopfilter NTP loop filter
packets NTP packets
params NTP clock parameters
select NTP clock selection
sync NTP clock synchronization
validity NTP peer clock validity
TokyoASA1# sh ntp stat
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 99.9984 Hz, actual freq is 99.9984 Hz, precision is 2**6
reference time is cfa3cae4.3dd6a89e (15:40:20.241 UTC Sun Aug 23 2010)
clock offset is -377969342.9594 msec, root delay is 2.04 msec
root dispersion is 15262547.68 msec, peer dispersion is 16000.00 msec
TokyoASA1# sh ntp ass
address ref clock st when poll reach delay offset disp
~153.6.3.3 .LOCL. 1 26 64 0 2.0 -37796 16000.
* master (synced), # master (unsynced), + selected, – candidate, ~ configured

Some debug comes next :

TokyoASA1# NTP: Authentication key 1
NTP: 153.6.3.3 reachable
NTP: sync change
NTP: peer stratum change
TokyoASA1# sh ntp stat
Clock is synchronized, stratum 2, reference is 153.6.3.3
nominal freq is 99.9984 Hz, actual freq is 99.9984 Hz, precision is 2**6
reference time is cf9e06b2.e6239822 (06:41:54.898 UTC Wed May 19 2010)
clock offset is -2.9681 msec, root delay is 1.95 msec
root dispersion is 21.58 msec, peer dispersion is 18.57 msec

Redundant interfaces in Cisco ASA

In Checkpoint they call it interface bonding – when will I stop dragging this Checkpoint everywhere ? – in Cisco ASA they called it interface redundancy. The idea is to provide for the physical link failure. That is – you combine two physical interfaces on the ASA into a virtual one, then you configure all the Layer 3 parameters on this virtual interface. At the same time only ONE of the interfaces in a group is active, if it fails ASA transparently switches to the next available interface in a group and all traffic passes through it. By default the first added to the group interface becomes active and all the rest become passive. At the end of the article there is some dry theory and facts, but now let’s plunge into code.
Warning !The moment you assign some physical interface to be a member of the redundant virtual interface ALL the existing configs on such interface are wiped out.
Create redundant interface (group) and assign 2 physical interfaces to it :

Santa#conf t
Santa(config)# interface Redundant1
Santa(config-if)# member-interface Ethernet0/0
Santa(config-if)# member-interface Ethernet0/2
Santa(config-if)#no nameif
Santa(config-if)#no security-level
Santa(config-if)#no ip address

Now basically we can start configuring nameif , IP address and security level for this Redundant1 interface but let’s be more creative and create some VLANs on it.

So far :

Santa#show run int
interface Redundant1
member-interface Ethernet0/0
member-interface Ethernet0/2
no nameif
no security-level
no ip address
Santa(config)# interface Redundant1.120

Santa(config-subif)# vlan 120
Santa(config-subif)# nameif dmz
Santa(config-subif)# security-level 50
Santa(config-subif)# ip address 10.0.0.12 255.255.255.0

To remind you state of the physical interfaces comprising the Redundant 1 is :

interface Ethernet0/2
no nameif
no security-level
no ip address

interface Ethernet0/0
no nameif
no security-level
no ip address

interface Redundant1
member-interface Ethernet0/0
member-interface Ethernet0/2
no nameif
no security-level
no ip address

Santa(config)# interface Redundant1.100
Santa(config-subif)# vlan 100
Santa(config-subif)# nameif outside
Santa(config-subif)# security-level 0
Santa(config-subif)# ip address 139.61.77.12 255.255.255.0

Now some verification is looming (pay attention to the bottom of the output where you can see which interface is currently active and how many state changes have happened so far) :

Santa# sh int redundant 1 detail
Interface Redundant1 “”, is up, line protocol is up

Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
Available but not configured via nameif
MAC address 001b.d589.9892, MTU not set
IP address unassigned
1870 packets input, 150617 bytes, 0 no buffer
Received 1329 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
766 L2 decode drops
264 packets output, 24326 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
0 lost carrier, 0 no carrier
input queue (curr/max packets): hardware (9/18) software (0/0)
output queue (curr/max packets): hardware (0/2) software (0/0)
Control Point Interface States:
Interface number is 10
Interface config status is active
Interface state is active
Redundancy Information:
Member Ethernet0/0(Active), Ethernet0/2
Last switchover at 07:25:35 UTC August 19 2010

And what about some debug ? Of course:
Santa(config)# debug redundant-interface ?

exec mode commands/options:
error errors
event events

Now let’s initiate shut on physical interface Ethernet0/2 that is now active
redundant interface Redundant1 switchover, active idx 1, stby idx 0

redundant interface Redundant1 switching active from Ethernet0/2 to Ethernet0/0.

Send gratuitous ARP on Redundant1.100.
Send gratuitous ARP on Redundant1.120.
redundant interface Redundant1 switch active to Ethernet0/0 done.

Switch has happened, now verify it:

Santa(config-if)# sh int redundant 1 det
Interface Redundant1 “”, is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
Available but not configured via nameif
MAC address 001b.d589.9892, MTU not set
IP address unassigned
2284 packets input, 187559 bytes, 0 no buffer
Received 1544 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
797 L2 decode drops
296 packets output, 27430 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collisions, 0 deferred
0 lost carrier, 0 no carrier
input queue (curr/max packets): hardware (8/18) software (0/0)
output queue (curr/max packets): hardware (0/5) software (0/0)

Control Point Interface States:

Interface number is 10
Interface config status is active
Interface state is active
Redundancy Information:

Member Ethernet0/0(Active), Ethernet0/2
Last switchover at 07:57:11 UTC August 19 2010

Having done a bit practice the dry theory comes next.

  • You can define up to 8 Redundant interfaces (if you have ASA 5580 why not?);
  • All the interfaces in the same group should be of the same type (Ethernet with Fiber won’t go well) ;
  • Only one interface is passing production traffic at any given moment;
  • Redundant interface gets by default MAC address of the first added to it interface, configurable;<
  • When fail over happens to the second interface, it takes over MAC address of its previously active neighbour to prevent loss of traffic. If MAC is configured especially and manually it remains the same;
  • You can force some interface to become Active using the command:
    Santa# redundant-interface redundant active-member <if_name>
  • Redundant interfaces are compatible with fail over feature.

For even more information , see:
ASA 8.3 interface configuration

Find SmartCenter address on the firewall module

I am sure there are gazillion ways to find the IP address of the managing this module SmartCenter but here comes the one I use. Works on firewall module as well as on the SmartCenter itself , even more – gives the same result, surprising no ?

[Expert@FW-XL1]# fw tab -t management_list -f
Using cptfmt
localhost:
Date: Aug 23, 2010
19:26:11 192.168.29.22 > : (+)====================================(+);
Table_Name:
management_list; : (+); Attributes: static, id 3; product: VPN-1 & FireWall-1;
19:26:11 192.168.29.22 > Key: c2ac5801, c2ac5801; product: VPN-1 & FireWall-1;

Playing with RIP on ASA

Cisco ASA and RIP
RIP has been with ASA for years and in this article I will try to cover all possible scenarios in configuring, misconfiguring. debugging and verifying it. As I come up with new ideas how to break the RIP on ASA I will update this article as well.
As it would be expected ASA has a bit limited version of RIP daemon as compared with IOS one. Major tasks you my be required to do :

  • Enable RIP on the ASA;
  • Dictate the version to work with – RIP v1 or RIP v2;
  • Specify networks RIP protocol will be active for;
  • Exclude some interfaces from active advertising RIP on them but allow to get
    RIP updates on them , i.e. passive interface(s);
  • Decide whether you want auto-summarization or not. Default is on;
  • Enable Rip updates authentication and whether it should be
    encrypted (MD5 mode) or clear text (text mode);
  • If using authentication define authentication keys under relevant interfaces;
  • To make your life harder you will be asked to redistribute;
  • Finally verify and debug RIP operation.

SO let’s get our hands dirty.
Enable RIP routing process.

ASA#conf t
ASA(config)# router rip
TokyoASA(config-router)#

Set it to run exclusively version 2 . ASA doesn’t know to mix version
2 and 1 as IOS does.

TokyoASA(config-router)# version 2

Networks to be active for . You should specify classful nets or even if you specify anything different after you enter such networks ASA will automatically turn them into classful ones anyway.

TokyoASA(config-router)# network 5.0.0.0

Verifying configuration so far:

TokyoASA(config-router)# sh run router
router rip
network 5.0.0.0
version 2

You will most probably want to disable summarization :

TokyoASA(config-router)# no auto-summary

Exclude some interface from advertising on it:
– To suppress on ALL interfaces in one go:

TokyoASA(config-router)# passive-interface default

– To be more specific:

TokyoASA(config-router)# passive-interface outside

Authentication is configured exclusively under the interface :
– Dictate which authentication mode to use.

TokyoASA(config-if)# rip authentication mode md5

– Specify the key (password) and its id.

TokyoASA(config-if)# rip authentication key MYKEY key_id 33

Here is how it looks in show run interface :

interface Ethernet0/0
nameif outside
security-level 0
ip address 136.6.12.12 255.255.255.0
rip authentication mode md5
rip authentication key <removed> key_id 33

Redistribute. Just redistributing learned in other ways networks into the RIP would be boring. As usual you redistribute connected, static, ospf and rip (when working with the rest of the protocols).

TokyoASA(config-router)# redistribute ?
router mode commands/options:
connected Connected
ospf Open Shortest Path First (OSPF)
rip Routing Information Protocol (RIP)
static Static routes

Much more interesting is to implement some policy while redistributing using route-maps. As expected route-maps here are not what we used to know in IOS.
So what can you match for me ?

TokyoASA(config-route-map)# match ?
route-map mode commands/options:
interface Match first hop interface of route
ip Match IP address or next-hop or route-source
metric Match metric of route
route-type Match route-type of route

The most familiar and useful match on ACL lies here:

TokyoASA(config-route-map)# match ip ?
route-map mode commands/options:
address Match address of route or match packet
next-hop Match next-hop address of route
route-source Match advertising source address of route
TokyoASA(config-route-map)# match ip address FILTER-ACL
TokyoASA(config-route-map)# route-map RIPv2 permit 10
match ip address FILTER-ACL
match interface inside
TokyoASA(config-router)# redistribute connected route-map RIPv2 metric 13

About rest of the match conditions, I’ll cover them when talking about OSPF in ASA.

TokyoASA(config-route-map)# match route-type ?
route-map mode commands/options:
external Match external route (OSPF type 1/2)
internal Match internal route (including OSPF intra/inter area)
local Match locally generated route
nssa-external Match nssa-external route (OSPF type 1/2)

Filtering out routes in updates.
If you want to filter some networks in updates use distribute-list.

TokyoASA(config-router)# distribute-list MYACL ?
router mode commands/options:
in Filter incoming routing updates
out Filter outgoing routing updates

Now some debug is due.
Enable rip debug:

TokyoASA1# debug rip
TokyoASA1# sh debug
debug rip routing
debug rip database
debug rip events

Normal functioning protocol debug output:

add 10.0.2.0 255.255.255.0 via 0.0.0.0, connected metric [0/0]network
0.0.6.136 is now variably masked
add 136.6.0.0 255.255.0.0 via 0.0.0.0, connected metric [0/0]
RIP-DB: redist 10.0.0.0 255.255.255.0(metric 0, last interface dmz1) to RIP
RIP-DB: redist 10.0.2.0 255.255.255.0(metric 0, last interface dmz1) to RIP
RIP-DB: Get redist for network 10.0.2.0
RIP-DB: adding 10.0.2.0 255.255.255.0 (metric 0) via 0.0.0.0 on Ethernet0/2.120 to RIP database
RIP-DB: rip_create_ndb create 10.0.2.0 255.255.255.0, (best metric 4294967295)
RIP-DB: rip_create_rdb Create 10.0.2.0 255.255.255.0, (metric 0) via 0.0.0.0, Ethernet0/2.120(permanent)
RIP-DB: add 10.0.2.0 255.255.255.0 (metric 0) via 0.0.0.0 on Ethernet0/2.120 (donot_age)
RIP-DB: Adding new rndb entry 10.0.2.0 255.255.255.0
RIP-DB: rip_create_ndb create 10.0.0.0 255.0.0.0, (best metric 4294967295)
RIP-DB: rip_create_rdb Create 10.0.0.0 255.0.0.0, (metric 0) via 0.0.0.0, Null0(permanent)
RIP-DB: Created rip ndb summary entry for 10.0.0.0 255.0.0.0
RIP-DB: Adding new rndb entry 10.0.0.0 255.0.0.0 rip_route_adjust for dmz1 coming up
RIP: sending request on dmz1 to 224.0.0.9 rip_route_adjust for dmz1 coming up
RIP: sending request on dmz1 to 224.0.0.9
RIP: sending v2 flash update to 224.0.0.9 via dmz1 (10.0.2.120)
RIP: build flash update entries – suppressing null update
RIP: sending v2 update to 224.0.0.9 via dmz1 (10.0.2.120)
RIP: build update entries – suppressing null update

Now the authentication has been enabled but keys on 2 peers are not the same:

RIP: sending v2 update to 224.0.0.9 via inside (136.6.121.12)
RIP: build update entries
10.0.0.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.23.0 255.255.255.0 via 0.0.0.0, metric 2, tag 0 136.6.123.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.124.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0
RIP: Update contains 4 routes
RIP: Update queued
RIP: sending v2 update to 224.0.0.9 via dmz1 (10.0.0.120)
RIP: build update entries
136.6.23.0 255.255.255.0 via 0.0.0.0, metric 2, tag 0 136.6.121.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.123.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.124.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0
RIP: Update contains 4 routes
RIP: Update queued
RIP: Update sent via inside rip-len:92
RIP: Update sent via dmz1 rip-len:92
RIP: ignored v2 packet from 136.6.123.3 (invalid authentication)
RIP: sending v2 update to 224.0.0.9 via inside (136.6.121.12)
RIP: build update entries
10.0.0.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.23.0 255.255.255.0 via 0.0.0.0, metric 2, tag 0 136.6.123.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 136.6.124.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0
RIP: Update contains 4 routes
RIP: Update queued
RIP: sending v2 update to 224.0.0.9 via dmz1 (10.0.0.120)
RIP: build update entries

Subnet calculator in Checkpoint

Should you ever forget intricacies of the subnetting Checkpoint bothered not to strip subnetting calculator from their Splat – ipcalc, so use it and litter not your memory with useless info.
Given subnet show the 1st Ip (network) :

# ipcalc -n 192.168.34.45/27
NETWORK=192.168.34.32

Given subnet show the last IP (broadcast) :

# ipcalc -b 192.168.34.45/27
BROADCAST=192.168.34.63

Be careful though what you feed as no proof-reading is done by the ipcalc :

# ipcalc -b 192.168.34.45/33
BROADCAST=255.255.255.255

Restart Checkpoint Smart Center only

Neither mine nor new idea, but it comes to the top 10 questions I hear on a daily basis so here is how to restart Smart Center only, that is if it is a stand alone installation where Smartcenter resides on the same machine where the firewall module does,this command will stop then start Smart Center only NOT influencing the firewall function in anyway. This way firewalling will run uninterrupted with no down time.
I guess I took it from CPUG forum .Stop SmartCenter :
cpwd_admin stop -name FWM -path "$FWDIR/bin/fw" -command " fw kill fwm"

Start it again :
cpwd_admin start -name FWM -path "$FWDIR/bin/fwm" -command "fwm"
« Older posts Newer posts »

© 2016 yurisk.info

Theme by Anders NorenUp ↑