Cisco Identity Firewall ASA intergration with AD for firewall rules

Hey Guys

So this feature is pretty damn cool in my opinion, this feature is called Cisco ASA identity firewall

This feature is available in ASA Firmware 8.4.2, is part of the base License and looks great

Basically what it allows you to do is configure firewall rules not based on IP address but based on username or group membership in AD! The user doesn't need to login or anything complicated for this to work.

what happens is, The Cisco ASA talks to a piece of free software available from Cisco (no license required) that connects to AD and maps logged in users to IP addresses, in the background this is what the ASA Is looking at when it is evaluating access rules, but when your configuring it, you just say "block all Internet Traffic for users belonging to this group"

To quote Cisco:

"The key benefits of the Identity Firewall include:
• Decoupling network topology from security policies
• Simplifying the creation of security policies
• Providing the ability to easily identify user activities on network resources
• Simplify user activity monitoring
"

So, just to run you through the scenario

Let's say you have a user, User X who is a very important executive, this Very important executive travels all over to diffirent sites on your WAN, so his IP might be totally different each time, he also loves to VPN into your network all the time.

He INSISTS that he is able to run Bit Torrent when he is plugged into the network, but of course you ban it for everyone else.

So, what do you do in a normal situation? Put his Office in a separate VLAN and assign him a separate IP? Yep that could work for his office, but what about when he travels to different sites, what about when he connects over the VPN?

With Identity Firewall, you just specify an access-list that looks something like this:


access-list internetOut permit ip user DCDOMAIN\ImportantExecutive any any


You can see from the above, basically you just reference it as the Windows Domain ID then the userID

You could also specify a group

hostname(config)# access-list aclname extended
permit ip user-group SAMPLE\\group.marketing any any


What happens is, when the ASA is evaluating the rules, it queries the AD Connect Agent that you installed on a windows server, which keeps a mapping of the IP address to windows login details (it gets this info from Microsoft AD) the AD connect agent is constantly updating as users log in and out, it also receives information from the ASA whenever a user log's in to the VPN and makes sure it gets their IP address details too!


You can see how this could greatly simplify your firewall configuration and allow rapid changes. It is a powerful tool and I can't wait to get my hands on ASA running 8.4.2 to try it out and show you all how to configure it! (Donations of ASA's kindly welcomed :p)


Debugging crypto properly, getting all those lovely attributes you dont normally get

hi Guys

I am not sure how many of you have dealt with IPSEC and VRF, but its quite complicated, what makes it even more complicated is trying to troubleshoot it, it can be a VERY difficult process. Below are some commands I learnt about recently that provide a HUGE level of debugging:

#show debug


Cryptographic Subsystem:
Crypto ISAKMP debugging is on (actual command is debug crypto isakmp)
Crypto ISAKMP Error debugging is on (actual command is debug crypto isakmp error)


IKEV2:
IKEV2 error debugging is on (actual command is debug crypto ikev2 event)
IKEV2 terse debugging is on
IKEV2 event debugging is on
PKI:
verbose debug output debugging is on (this is the _KEY_ command, debug crypto verbose)

The last one is the most important one, as with it you get beautiful debug output that shows you things like, was the keychain actually hit, if it was where the attributes acceptable, what attributes did the other end send etc


A voice post! How to take an ISDN channel out service for E1

Hi Guys

Finally I found a post to make about voice! I am sure we have all been in the situation where we have had to take ISDN channels out of service to help diagnose a problem (Some customers for example, seem to have one way voice issues on single channels, or other such problems) and it is helpful when you can confirm what the heck the issue is by taking out an ISDN channel, or just as a quick stop gap measure while you wait for new DSP's or the telco to fix the issue

Here is how to do it on an E1:

Router(config)#interface serial 0:15

Router(config-if)#isdn service b_channel X state 2

I found this at:

https://supportforums.cisco.com/docs/DOC-4989

This works for SIP and H.323 gateways, for MGCP you need to set the enterprise parameter.

Very good IT Related article

I don't often do this, but This is the best bit of IT hiring advice I have ever heard/read:
http://www.networkworld.com/news/2011/081511-recruiting-atrophy.html?page=2

Configuring Stack Power, what they DON'T tell you

Hi Guys

So their is a guide to configuring Stack Power for 3750x's available at:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/12.2_58_se/configuration/guide/swstkpwr.html#wp1015591

However, to say it is incomplete would be an understatement. If you just read this document, it appears all you have to do is plug the power cables in and away it goes, this however is not accurate, and sometimes it can be a little flakely, so without further ado, please enjoy my guide on getting stack power configured:

Step 1.
Get all your switches powered up using their own power, stack them together as a data stack, The directions change a little bit if your not using a stack OR if you don't have enough power cables and want to just get a few switches up using only one power cable, Your directions are a little diffirent. Leave a comment if you need help.



Step 2.
So, first of all you need to issue a command like such:


show stack-power

Power stack name: Powerstack-1
Stack mode: Power sharing strict
Stack topology: Standalone
Switch 3:
Power budget: 1063
Low port priority value: 22
High port priority value: 13
Switch priority value: 4
Port 1 status: Shut
Port 2 status: Shut
Neighbor on port 1: 0000.0000.0000
Neighbor on port 2: 0000.0000.0000

If you look at this output, the key words are Port 1 Status: Shut and Port 2 Status: Shut

This means that the stack power is not turned on yet on those ports, to turn it on issue this command:


switch1#stack-power switch 1 port 1 enable
switch1#stack-power switch 1 port 2 enable

This will enable stack power across the ports, you need to do this on every switch in your stack, so for example:

switch1#stack-power switch 2 port 1 enable
switch1#stack-power switch 2 port 2 enable

and so on and so forth for each switch, now you should also ensure all your switches are part of the same Power Stack (each switch can belong to one power stack group)

#show stack-power

Power stack name: Powerstack-1

Stack mode: Power sharing strict
Stack topology: Ring
Switch 1:
Power budget: 343
Low port priority value: 21
High port priority value: 12
Switch priority value: 3
Port 1 status: Connected
Port 2 status: Connected
Neighbor on port 1: 44d3.ca71.1c00
Neighbor on port 2: 44d3.ca70.0e00

Switch 2:
Power budget: 373
Low port priority value: 20
High port priority value: 11
Switch priority value: 2
Port 1 status: Connected
Port 2 status: Connected
Neighbor on port 1: 44d3.ca71.1b80
Neighbor on port 2: 44d3.ca71.1c00

Switch 3:
Power budget: 343
Low port priority value: 22
High port priority value: 13
Switch priority value: 4
Port 1 status: Connected
Port 2 status: Connected
Neighbor on port 1: 44d3.ca70.0e00
Neighbor on port 2: 44d3.ca71.1b80



the configuration to place them all in the same group like this is shown below:

stack-power stack Powerstack-1

stack-power switch 1
stack Powerstack-1
stack-power switch 2
stack Powerstack-1
stack-power switch 3
stack Powerstack-1

This will place all three switches into the same power stack.

Now finally, the next step is to configure any parameters we might want such as setting one switch to have a higher priority than the other.

So, every switch has a priority, the higher priority switches have there power shedded first (confusing i know)

within the switch, there are also high-priority POE ports and low-priority POE Ports, you set your high priority POE ports with a lower value and your low-priority ports with a higher value

Note that a switches priority must be LOWER than its own ports, you could also use these values to make it so that, lets say you had three switches, you could say if you need to shed power, shed power from the low-priority POE ports for switch 1 and 2 first, THEN if still not enough power just shut down switch 3, then if still not enough power shut down switch 2 then 1

so you can see you can really ensure that each switch has a particular priority and same for the ports

Here is an example



switch#show stack-power
Power stack name: Powerstack-1
Stack mode: Power sharing strict
Stack topology: Ring
Switch 1:
Power budget: 343
Low port priority value: 11
High port priority value: 10
Switch priority value: 1
Port 1 status: Connected
Port 2 status: Connected
Neighbor on port 1: 44d3.ca71.1c00
Neighbor on port 2: 44d3.ca70.0e00

Switch 3:
Power budget: 343
Low port priority value: 15
High port priority value: 14
Switch priority value: 3
Port 1 status: Connected
Port 2 status: Connected
Neighbor on port 1: 44d3.ca70.0e00
Neighbor on port 2: 44d3.ca71.1b80

Switch 2:
Power budget: 373
Low port priority value: 13
High port priority value: 12
Switch priority value: 2
Port 1 status: Connected
Port 2 status: Connected
Neighbor on port 1: 44d3.ca71.1b80
Neighbor on port 2: 44d3.ca71.1c00

In this example, low priority ports on switch 3 are shed first, then the high priority ports

then on switch 2, low priority ports are shed first, then high priority

then on switch 1, low priority ports are shed first, then high priority

Finally, if enough power is not available with all POE ports turned off, switch 3 is turned off first, followed by switch 2, then switch 1


However, in the example above we have enough power to power all three switches with one power supply

OTV + first hop redundancy

http://www.netcraftsmen.net/component/content/article/69-data-center/905.html

Good article!

Bidirectional Forwarding Detection

Hi Guys

So right now I am doing a Cisco Nexus 1000,5000,7000 Training course and during this course I came across for the first time a protocol you may or may not have heard of called Bidirectional Forwarding Detection that can be _VERY_ Useful to all you BGP guys out there, heck to anyone running a routing protocol.

When I first started looking into this protocol, it appeared it was something juniper had actually developed, I was like finally a protocol Juniper developed! But Alas, Junipers own slides refer to the fact it's a joint effort between Juniper and Cisco (Source: http://meetings.ripe.net/ripe-48/presentations/ripe48-eof-bfd.pdf Last Page) But it is great to see them working together to help us network engineers get even better protocols and products!

So, what is Bidirectional Forwarding Detection and why should I care?

So let's say you have dual homed internet connections, via BGP for example, or maybe you have two connections via OSPF for your internal network, whatever the case may be, you might have run into this problem:

Time it takes to detect a dead peer is painfully long!

Sure sure, you can tweak the timers for OSPF and to a certain extent BGP, but wouldn't it be nice if there was a way to easily add this capability without having to affect BGP/OSPF

Enter BFD, BFD provides _VERY_ fast dead peer detection, and can then feed this information into your routing protocol which can then know the peer is dead very quickly and converge

It is super easy to configure, works on all all media types, encapsulations, topologies, and routing protocols.

Let's get onto some configuration!


Here I have two routers connected via a single gigabit link running BGP and OSPF, nothing special so far:

R1#show run | sect router
router ospf 1
network 192.168.1.0 0.0.0.3 area 0
router bgp 65400
bgp log-neighbor-changes
neighbor 192.168.1.1 remote-as 65400

R2#show run | sect router
router ospf 1
network 192.168.1.0 0.0.0.3 area 0
router bgp 65400
bgp log-neighbor-changes
neighbor 192.168.1.2 remote-as 65400




They are neighbors:

R2#show ip bgp sum
BGP router identifier 192.168.1.1, local AS number 65400
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.2 4 65400 52 52 1 0 0 00:43:22 0

R2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.1.2 1 FULL/DR 00:00:33 192.168.1.2 GigabitEthernet1/0


so far so good, next let's configure BFD

So currently the only supported BFD mode is Asynchronous mode, this means that BOTH ends must be configured to support it, so if your ISP on your BGP won't provide it at the moment your shit out of luck. But I believe there is a mode of BFD called demand mode that might address this.

So, to configure it, first we go to the interface that has our peering relationship and enter:

bfd interval <50-999> min_rx <1-999> multiplier <3-50>

So the BFD interval is how often we send BFD's, the min_rx is how often we except to receive the BFD's (it can be more frequently though that is fine, but we are basically saying if we dont receive one within this time frame consider it a timeout) and then finally we have a multiplier which is how many we can miss before we consider the interface down

Now unfortunately, and I would love to see if someone can correct me, but doing this alone is not enough to turn on BFD and actually see if the other end has it turned on, what you need to do is:

router ospf 1
bfd all-interface
!

This turns on BFD for any interface that has a BFD interval configured.

If the peer goes down, you will see a message like this:


*Aug 10 18:24:59.323: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on GigabitEthernet1/0 from FULL to DOWN, Neighbor Down: BFD node down

Pretty cool hey? And I tell you when I was testing it, it went down in absolute microseconds when I did this, so very funky little feature to help with convergence times.

Let's see how to configure it with BGP (which is probably more relevant because let's face it, OSPF convergence times can be tuned and are not that bad, BGP has the bad convergence times)

so with BGP, same again with the BFD interval:



interface GigabitEthernet1/0
ip address 192.168.1.2 255.255.255.252
negotiation auto
bfd interval 100 min_rx 100 multiplier 3
!

Then you go ahead and enable it on your BGP Peer:

router bgp 65400
neighbor 192.168.1.1 remote-as 65400
neighbor 192.168.1.1 fall-over bfd
!

Easy as that! Super easy to turn on as you can see, you can verify with:



R2#show ip bgp neighbor
BGP neighbor is 192.168.1.1, remote AS 65400, internal link
Fall over configured for session
BFD is configured.

To verify BFD itself is working, you have:

R1#show bfd neighbors


NeighAddr LD/RD RH/RS State Int
192.168.1.2 1/1 Up Up Gi1/0

Pretty cool hey!



Here are some references on how to configure it both for Juniper and Cisco

Cisco:
http://www.cisco.com/en/US/technologies/tk648/tk365/tk480/technologies_white_paper0900aecd80244005.html

Juniper:
http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/configuring-the-bfd-protocol_3.html

New 3750X models

Hi Guys

you might be as interested as me to know that their is now 12 Port and 24 Port SFP 3750X switches, finally!
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps10745/product_bulletin_c25-675378.html

Popular old posts.