As IOS FW stateful failover is stated in the blueprint I would say theres a good chance.
And as I keep hearing from Scot in his audio bootcamps "Anythings Fair Game!" =) On Mon, May 18, 2009 at 9:52 PM, Shawn Mesiatowsky <[email protected]>wrote: > Will SSO for CBAC and VPN be tested? > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Paul Stewart > *Sent:* Saturday, May 16, 2009 2:42 PM > *To:* [email protected] > *Subject:* Re: [OSL | CCIE_Security] CCIE_Security Digest, Vol 35, Issue > 30 > > > > On the bright side, I still doesn't appear to support zfw. That means we > either have to deal with CBAC and Possible SSO on a group of routers, or ZFW > and no SSO. > > > Today's Topics: > > 1. Re: IOS FW Stateful redundancy (Stuart Hare) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 16 May 2009 19:23:42 +0100 > From: Stuart Hare <[email protected]> > Subject: Re: [OSL | CCIE_Security] IOS FW Stateful redundancy > To: Paul Stewart <[email protected]> > Cc: Cisco certification <[email protected]>, OSL Security > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Ive got to tend to agree after reading that and from what I have seen > today. > Stability is not a word I would associate with this feature. > > Strange thing is my standby router R4 has randomly restarted even though I > havent manually changed the interface states, which is worrying. > > Another downside is that I have incorporated some granular protocol > inspection (which as far as I can tell is just using PAM with CBAC) on > these > devices, and that doesnt work either although both devices are identically > configured in terms of PAM and CBAC. > I have tried to removing cbac from the interface and rebooting both devices > and this just doesnt work. > You never see get the session table entry on secondary device for the > custom > apps. > > R2# > *May 16 19:07:26.503: %FW-6-SESS_AUDIT_TRAIL_START: Start user-HTTP8004 > session: initiator (10.1.1.100:4925) -- responder (192.1.246.6:8004) > R2# > > R4# > *May 16 19:07:59.579: %FW_HA-6-PROT_MISMATCH: Firewall High availability - > L4 protocol/mapping for user defined application mismatch between active > and > standby > R4# > > Generally not a feature I plan to use and Im hoping I do not see this in my > lab, sods law says it will be though :-( > > Stu > > On Sat, May 16, 2009 at 6:45 PM, Paul Stewart <[email protected]> wrote: > > > Stuart, > > > > I am doing the same thing with SSO right now. I am seeing similar > things. > > What I have found is that as a device transitions from active mode to > > standby mode, it reboots. I thought it was a bug at first. At the URL > > below, you will find something that seems to say that is the way it > works. > > I have also been playing with IPSec Profiles within the redundancy and > have > > had some issue there. Secifically, one of my routers went into "Socket > > Error" in show redundancy inter-device. The only way I cleared it up was > to > > remove the security profile inside of the redundancy config and re add > it. > > Ironically, the SA's were passing traffic. > > > > I really don't feel like I would implement SSO in production. I think I > > understand it quite well now, but it is not nearly as good of way to do > > things as the ASA does with its failover. Moreover, IOS doesn't seem to > > have a mechanism to preserve the MAC address on nat translations, so it > is > > important that the nat pool be behind the interface IP subnet and not > part > > of it. Then the MAC address is a moot point and inbound traffic is > framed > > toward the hsrp mac address. > > > > See this url on SSO > > > > > http://www.cisco.com/en/US/prod/collateral/routers/ps5855/white_paper_c11_472858.html > > > > On Sat, May 16, 2009 at 12:00 PM, < > > [email protected]> wrote: > > > >> Send CCIE_Security mailing list submissions to > >> [email protected] > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> http://onlinestudylist.com/mailman/listinfo/ccie_security > >> or, via email, send a message with subject or body 'help' to > >> [email protected] > >> > >> You can reach the person managing the list at > >> [email protected] > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of CCIE_Security digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: LAB1B - ASA Static PAT Error (Tyson Scott) > >> 2. OT: Jumbo frames / large packets (Stuart Hare) > >> 3. Re: OT: Jumbo frames / large packets (Pieter-Jan Nefkens) > >> 4. Global & Interface policy precedence (Dnyaneshwar Gore) > >> 5. IOS FW Stateful redundancy (Stuart Hare) > >> 6. FPM (Stuart Hare) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Thu, 14 May 2009 15:09:38 -0400 > >> From: "Tyson Scott" <[email protected]> > >> Subject: Re: [OSL | CCIE_Security] LAB1B - ASA Static PAT Error > >> To: "'Stuart Hare'" <[email protected]> > >> Cc: 'Cisco certification' <[email protected]>, 'OSL Security' > >> <[email protected]> > >> Message-ID: <000901c9d4c7$899c1da0$9cd458...@com> > >> Content-Type: text/plain; charset="us-ascii" > >> > >> Stuart this should work fine. I believe it is shown in the verification > >> for > >> it working. Did you enable SSH for the ASA on the outside using > >> > >> Ssh permit x.x.x.x x.x.x.x outside as Dave is asking below? > >> > >> > >> > >> Regards, > >> > >> > >> > >> Tyson Scott - CCIE #13513 R&S and Security > >> > >> Technical Instructor - IPexpert, Inc. > >> > >> > >> Telephone: +1.810.326.1444 > >> Cell: +1.248.504.7309 > >> Fax: +1.810.454.0130 > >> Mailto: [email protected] > >> > >> > >> > >> Join our free online support and peer group communities: > >> <http://www.IPexpert.com/communities<http://www.ipexpert.com/communities> > <http://www.ipexpert.com/communities>> > >> http://www.IPexpert.com/communities<http://www.ipexpert.com/communities>< > http://www.ipexpert.com/communities> > >> > >> > >> > >> IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On > >> Demand > >> and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE > >> Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE > Storage > >> Lab Certifications. > >> > >> > >> > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of Stuart > >> Hare > >> Sent: Thursday, May 14, 2009 1:34 PM > >> Cc: Cisco certification; OSL Security > >> Subject: Re: [OSL | CCIE_Security] LAB1B - ASA Static PAT Error > >> > >> > >> > >> Great! apparently this is on the resolved caveat list for ASA 8.0(4). > >> > >> > >> > >> Evidently this is not the case =) > >> > >> > >> > >> > >> > http://www.cisco.com/en/US/docs/security/asa/asa80/release/notes/arn804n.htm > >> l > >> > >> > >> > >> > >> On Thu, May 14, 2009 at 6:01 PM, Dave Craddock <[email protected]> > wrote: > >> > >> do you have ssh on the outside as you are using the interface and this > is > >> the asa's ssh address ? > >> > >> > >> > >> ________________________________ > >> > >> From: [email protected] on behalf of Stuart > Hare > >> Sent: Thu 14/05/2009 18:07 > >> To: OSL Security; Cisco certification > >> Subject: [OSL | CCIE_Security] LAB1B - ASA Static PAT Error > >> > >> > >> > >> Has anyone come across the following error when using static PAT. > >> > >> asa(config)# static (DMZ7,outside) tcp interface ssh 10.7.7.7 ssh > netmask > >> 255.255.255.255 > >> ERROR: unable to reserve port 22 for static PAT > >> ERROR: unable to download policy > >> > >> Other static PAT statements are in and working correctly. > >> static (DMZ8,outside) tcp 192.1.24.8 www 10.8.8.8 www netmask > >> 255.255.255.255 > >> static (DMZ8,outside) tcp 192.1.24.8 telnet 10.8.8.8 telnet netmask > >> 255.255.255.255 > >> static (DMZ8,outside) tcp 192.1.24.8 8080 8.8.8.8 www netmask > >> 255.255.255.255 > >> static (DMZ7,outside) tcp interface https 10.7.7.7 https netmask > >> 255.255.255.255 > >> > >> Not came across this before, any ideas? > >> > >> Stu > >> > >> -- > >> Stuart Hare > >> > >> [email protected] > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> Stuart Hare > >> > >> [email protected] > >> > >> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Fri, 15 May 2009 13:46:35 +0100 > >> From: Stuart Hare <[email protected]> > >> Subject: [OSL | CCIE_Security] OT: Jumbo frames / large packets > >> To: OSL Security <[email protected]>, Cisco > >> certification <[email protected]> > >> Message-ID: > >> <[email protected]> > >> Content-Type: text/plain; charset="us-ascii" > >> > >> Guys > >> > >> I have a VMware virtaul server that is using enhanced NIC so has jumbo > >> frames and tcp offloading enabled. > >> And we are seeing performance issues to the app on this server. > >> When we capture the traffic with wireshark on the server we see a huge > >> amount jumbo frames/packets (anywhere from 2500 to 32000 bytes), that we > >> are > >> not seeing on the network or end client, as well as of a lot tcp errors, > >> in > >> terms of bad checksums and retransmissions. On top of this each of the > >> jumbo > >> frames/packets have the DF bit set, which immediately tells me that > these > >> packets will be dropped by the lower default MTU on the network devices, > >> due > >> to no fragmentatoin occurring. > >> > >> My problem is Im struggling to pinpoint this and find where these > packets > >> are being dropped if at all. > >> I was hoping to see this maybe from the interfaces counters on the > >> switches > >> but I see nothing. > >> Or maybe this is happening at the physically interface of the VM host > >> server? > >> > >> Is my logic around this correct or am i missing something? > >> > >> Cheers > >> Stu > >> > >> -- > >> Stuart Hare > >> > >> [email protected] > >> > >> > >> > >> ------------------------------ > >> > >> Message: 3 > >> Date: Sat, 16 May 2009 11:44:33 +0200 > >> From: Pieter-Jan Nefkens <[email protected]> > >> Subject: Re: [OSL | CCIE_Security] OT: Jumbo frames / large packets > >> To: Stuart Hare <[email protected]> > >> Cc: Cisco certification <[email protected]>, OSL Security > >> <[email protected]> > >> Message-ID: <[email protected]> > >> Content-Type: text/plain; charset="us-ascii" > >> > >> Hello Stuart, > >> > >> Do you have access to the switch that has the connection between the > >> VMWare server and the rest of the network? > >> If it's a cisco, check the command > >> > >> show interfaces <interface> counters all > >> > >> It will show you if the problem is in the netwerk (from that switch to > >> the client PC) or in the vmware environment by looking at the jumbo > >> frames counters. > >> > >> Check out this document: > >> > http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a00801350c8.shtml > >> > >> You could do this step-by-step on the LAN infrastructure, and then > >> check on the firewall / router if the jumbo frames are dropped. > >> > >> There should be a way to determine (I think with SNMP) to see what > >> packets are dropped. I would go from the switch connecting to the > >> vmware server up the path to the client PC.. > >> > >> Pieter-Jan > >> > >> On 15 mei 2009, at 14:46, Stuart Hare wrote: > >> > >> > Guys > >> > > >> > I have a VMware virtaul server that is using enhanced NIC so has jumbo > >> > frames and tcp offloading enabled. > >> > And we are seeing performance issues to the app on this server. > >> > When we capture the traffic with wireshark on the server we see a huge > >> > amount jumbo frames/packets (anywhere from 2500 to 32000 bytes), > >> > that we are > >> > not seeing on the network or end client, as well as of a lot tcp > >> > errors, in > >> > terms of bad checksums and retransmissions. On top of this each of > >> > the jumbo > >> > frames/packets have the DF bit set, which immediately tells me that > >> > these > >> > packets will be dropped by the lower default MTU on the network > >> > devices, due > >> > to no fragmentatoin occurring. > >> > > >> > My problem is Im struggling to pinpoint this and find where these > >> > packets > >> > are being dropped if at all. > >> > I was hoping to see this maybe from the interfaces counters on the > >> > switches > >> > but I see nothing. > >> > Or maybe this is happening at the physically interface of the VM host > >> > server? > >> > > >> > Is my logic around this correct or am i missing something? > >> > > >> > Cheers > >> > Stu > >> > > >> > -- > >> > Stuart Hare > >> > > >> > [email protected] > >> > > >> > >> --- > >> Nefkens Advies > >> Enk 26 > >> 4214 DD Vuren > >> The Netherlands > >> > >> Tel: +31 183 634730 > >> Fax: +31 183 690113 > >> Cell: +31 654 323221 > >> Email: [email protected] > >> Web: http://www.nefkensadvies.nl/ > >> > >> -------------- next part -------------- > >> A non-text attachment was scrubbed... > >> Name: green.gif > >> Type: image/gif > >> Size: 87 bytes > >> Desc: not available > >> Url : > >> > http://onlinestudylist.com/pipermail/ccie_security/attachments/20090516/eff03770/attachment-0001.gif > >> -------------- next part -------------- > >> Think before you print. > >> > >> > >> > >> > >> > >> ------------------------------ > >> > >> Message: 4 > >> Date: Sat, 16 May 2009 16:00:44 +0530 > >> From: Dnyaneshwar Gore <[email protected]> > >> Subject: [OSL | CCIE_Security] Global & Interface policy precedence > >> To: [email protected], [email protected] > >> Message-ID: > >> <[email protected]> > >> Content-Type: text/plain; charset="iso-8859-1" > >> > >> Hi, > >> > >> I am referring to ASA ver 8.0 config guide. On page 16-23, it is > mentioned > >> that "Interface service policies take precedence over the global service > >> policy for a given feature." > >> > >> But on page 25-5, they are saying "For example, if you configure > standard > >> priority queueing for the global policy, and then configure traffic > >> shaping > >> for a specific interface, the feature you configured last is rejected > >> because the global policy overlaps the interface policy." > >> > >> Here contradictory explanation is given for interface policy and global > >> policy implementation on interface. > >> > >> Kindly help me to understand this. > >> > >> Regards, > >> D.M.Gore > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: > >> > http://onlinestudylist.com/pipermail/ccie_security/attachments/20090516/0b23cabe/attachment-0001.htm > >> > >> ------------------------------ > >> > >> Message: 5 > >> Date: Sat, 16 May 2009 16:20:53 +0100 > >> From: Stuart Hare <[email protected]> > >> Subject: [OSL | CCIE_Security] IOS FW Stateful redundancy > >> To: OSL Security <[email protected]>, Cisco > >> certification <[email protected]> > >> Message-ID: > >> <[email protected]> > >> Content-Type: text/plain; charset="iso-8859-1" > >> > >> > >> Im currently labbing up IOS firewall redundancy. > >> > >> I have 2 routers R2 & R4 setup for this and although everythings seem to > >> work ok I have one small issue. > >> When I shut an interface to test the failover, it failovers over as > >> expected > >> but R2 (the primary device) proceeds to reload itself. > >> > >> R2(config)#int vlan 246 > >> R2(config-if)#sh > >> R2(config-if)# > >> *May 16 15:42:28.375: %HSRP-5-STATECHANGE: Vlan246 Grp 246 state Active > -> > >> Init > >> *May 16 15:42:28.375: %TRACKING-5-STATE: 1 interface Vl246 line-protocol > >> Up->Down > >> *May 16 15:42:29.015: %HSRP-5-STATECHANGE: Vlan24 Grp 24 state Active -> > >> Speak > >> *May 16 15:42:29.015: %RF_INTERDEV-4-RELOAD: % RF induced self-reload. > my > >> state = ACTIVE peer state = STANDBY HOT > >> R2(config-if)# > >> *May 16 15:42:29.331: %RF-5-RF_RELOAD: Peer reload. Reason: > >> R2(config-if)# > >> > >> Once R2 comes back up and becomes the active device then R4 reloads > >> itself. > >> > >> Is this a default feature of SSO/IPC? If so is there a cmd that prevents > >> this action? > >> Or is this a bug? > >> > >> For reference I used the following guide to configure this: > >> http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_sfo.html#wp1164398 > >> > >> Cheers > >> Stu > >> > >> -- > >> Stuart Hare > >> > >> [email protected] > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: > >> > http://onlinestudylist.com/pipermail/ccie_security/attachments/20090516/1b2956af/attachment-0001.htm > >> > >> ------------------------------ > >> > >> Message: 6 > >> Date: Sat, 16 May 2009 16:40:33 +0100 > >> From: Stuart Hare <[email protected]> > >> Subject: [OSL | CCIE_Security] FPM > >> To: OSL Security <[email protected]>, Cisco > >> certification <[email protected]> > >> Message-ID: > >> <[email protected]> > >> Content-Type: text/plain; charset="iso-8859-1" > >> > >> Ive been going over the guides for Access Control and Flexible Pattern > >> Matching. > >> Although theres good info around how to configure this, I cant find > >> anything > >> that explains the thought process or logic for the patterns or the > offsets > >> used to classify the traffic. > >> > >> Is there a decent doc that explains this or can someone shed some light > on > >> this for me please? > >> > >> Many thanks > >> Stu > >> > >> -- > >> Stuart Hare > >> > >> [email protected] > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: > >> > http://onlinestudylist.com/pipermail/ccie_security/attachments/20090516/f2515ff9/attachment-0001.htm > >> > >> End of CCIE_Security Digest, Vol 35, Issue 28 > >> ********************************************* > >> > > > > > > > -- > Stuart Hare > > [email protected] > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://onlinestudylist.com/pipermail/ccie_security/attachments/20090516/d0105b97/attachment.htm > > End of CCIE_Security Digest, Vol 35, Issue 30 > ********************************************* > > > -- Stuart Hare [email protected]
