fortigate advance reformat and install

Sometime in our fortigate firewalls, we develop issues with the image and flash storage. In this post we will look at a FWF60B and the recovering and restoring the image on the internal flash storage.

1st if  your firewall boots with the following error or any errors or just flat out don't boot;

This is a good sign or bad things ahead. But have no fear we can recover.

2nd, you will need to  pull the power cord and interrupt the boot process & reinstall and/or format

note:  here we will  reformat and then install a fresh image into the flash using TFTP-server. It will require that you have access to fortinet support for downloading the appropiate image

https://support.fortinet.com/login/UserLogin.aspx

Okay so let's reformat and install our new image;

tftp-server = located at 192.168.1.168
fortigate =  temporary configured at .188
netmask  = /24
image = FWF_60B-v400-buildXXXX-FORTINET.out ( xxxx =  the version build )

Okay that's simple. And as you can see  the unit will validate the  image and reboot the firewall after the recovering.

Lastly, if you suspect  hardware issues;  Fortinet provides a diagnostic image that  you can download and BOOT and run extended  diagnostics. These images are known as  HQIP and once again, require access to support @ fortinet.

http://emea.fortinet.net/fortinet/aht/index.php

So if you suspect hardware issues, grab the HQIP file for your model and run the diagnostics & before reinstalling the image.


Ken Felix
Freelance Network/Security Engineer

kfelix ----a--t----socpuppets ---.---com


   ^     ^
=( * O )=
      @
     / | \

The confusion over dhcp option#82

Option 82 has drawn a lot of confusion, and in this post we will look very closely at the  option#82 and "Relay Agent information" that's provided to the DHCP server. Keep in mind, if a dhcp-server does not recognize the option#82 field, it will just ignore this option. This option is  optional.

DHCP relay agents offer this option for providing  client information to the DHCP server. This information could consists of the switch vlan and port information or other circuit information as deemed by the server provider. A lot of service providers that uses  PPPoE,  inserts the option 82 information for tracking, statistics and billing means.

We will use a  cisco 3560 and with dhcp snooping enable with the default of installing DHCP relay agent information for this post.

1st here our dhcp-snooping configuration for vlan 1,2, & 333

We also enable dhcp trust for gi 0/1,  which is the port that our  dhcp-server is located at ;

note: my dhcp server on port gi 0/1 ignores options #82 information

This set the base for our diagnostics and capture. I'm capturing traffic on gi 0/1 and will replay this using tshark and with the display filter " 'bootp.option.agent_information_option.suboption' "


1st here's our  show  DHCP snooping output  for vlan 1, 2, 333

Notice the custom circuit-ids are not populated? 

by default a switch inserts the circuit-id in this fashion; vlan# module# and port # 

Okay here's a packet capture for a client in vlan1 on port #2,  and the option 82 details which reflects the  client vlan and port #.
 

Notice the  circuit-id 000400010102 ?

This reflects the client at port #2 and vlan #1

If we move the client to port#5, the display would look like the following;

Notice the  circuit-id 000400010105 ?



Okay that was simple. Now let's look at the  agent-remote-ID. This value is computed from the  switch 1st available mac_address

DHCP snoop or dhcp relay information configurations, will insert this mac_address for the  Agent Remote ID. So keep this in mind if your looking at  remote-id information.

And finally, I will reconfigure the above for vlan 2 and then vlan 333 so you can see  the change in the client information that's relayed to the DHCP server;


vlan2

vlan333 ( hex 0x14d )

And finally, to disable this feature ;


( for a  dhcp snooping enable switch )

( for a  ip helper  )

 I hope this helps with your understanding of the option #82 and it's place with regards to the DHCP relay and server.

Ken Felix
Freelance Network/Security Engineer
kfelix ----@---- socpuppets ---.----com

    ^    ^
=( *  * )=
     @
    /  \

T-Mobile hotspot bypass ( gripe )

T-mobile seems to be enforcing  the use of our  phone & as a  wifi hotspot within some data plans.

I'm on a pre-pay plan at $70.00 a month unlimited data/voice/text,  and  been a customer of  t-mobile for  over 2.5 years with this  "unlimited plan". I've always used my  phone integral hotspot  for data access for a year or so. Approx 6 months ago, I switched to a pre-paid plan where  your taxes+fees are cheaper.    ( It saved me approx $25.00 per month btw )

It has disadvantages tho;

•  no billing or receipt available or details to your plan usage

• t-mobile stores and outlet seems to be clueless on the plan details from what I can tell

• t-mobile own website has not information post on the plan for the general public to review before acquiring that plan

• they enable some child protection block that I had to call and disable

• the billing alerts;  just plain-ass  sucks. As they keep sending me alert telling me  my account will expire, but I have  way over $120.00 on the account 

Now all of suddenly,  T-mobile starts issuing the following page  re-direction when tethering thru my  Nexus google phone

Okay,

So what they are doing exactly ?  They are  inspecting the  user-agent within the http browser request.

If the user-agent is NOT of some type of  mobile phone device, they redirect you to this page to make your life  miserable and to milk you for a plan upgrade or in my case I went to a  downgraded plan  from 70usd a month to 60usd  a month & with no unlimited data but now with hotspot capability  :(

Here's how you can bypass TMobile stupid little tricks & games.  ( The same works on ATT btw )

Install a User-Agent switcher and switch your browser agent to let's say;  a iphone, samsung or nexus phone.

reference:

https://addons.mozilla.org/en-us/firefox/addon/user-agent-switcher/

I used this trick in firefox & just to navigate any web firewalls.

In the above add-on tools, I have  iPhone3.0 selected for my  User-Agent. Keep in mind  the user-agent type & some types of websites, will reformat the display page for the mobile-device. So your google mail display would be slightly different than let's say a straight firefox or IE user.

It's silly that the phone companies have to resort to a" nickel and dime" you for everything and in this case the  they are NOT providing the wifi-hotspot,  but your phone and it's  native capability  are.

So instead of using let's say a T-Mobile usb jetpack stick & purchasing yet another device, plan and contract, T-mobile identifies us.  They really want  you to buy more devices such as ;

Why would they even care if the data is originating from a phone,  or a device tether thru the phone? Vrs another  stand-alone hotspot device? I'll answer that; " they are greedy "


I hope this trick comes in handy,  and if you refuse to be steered by the cell/telco phone companies.

https://addons.mozilla.org/en-us/firefox/addon/user-agent-switcher/

So stick it to em !  :)


Ken Felix
Freelance Network/Security Engineer
kfelix ---a---t--- socpuppets ----d---o---t----- com

The DNS Curve Ball

One of the biggest problems with DNS,  has always been the lack of security.

Any response from a DNS server, could be forged or hijacked. And we have no real means to identify the sender of the data.


DNSSEC ( DNS Security Extensions ) and DNSCurve are two unique means for securing  DNS traffic. The former  DOES NOT encrypt the  response from the server, it only applies "Authentication", where as the  latter ensure "Privacy".

DNScruve  ( DNS elliptci Cruve cryptology ) provides both authentication, and  encryption,  & for both ; "  DNS request and it's response"

Now some would ask why on earth would you care about security within DNS services ?


That's very easy, security within DNS would accomplish the following;


1:  ensure the response are from a legit DNS server

2:  reduce or eliminate a DNS reflection attack

3:  eliminated DNS poisoning 

4:  eliminate any DNS replays attacks


 Okay so with the above plus, why are we not seeing more use within DNS security ?

1:  Lack of enforcement within  our exterior security policy

2:  A lack for  mass supported DNS servers and clients

3:  A major gap in the lack of knowledge within IT sector,  and more specifically us  IT security folks

4: And with DNSSEC ; the complexity with setup and crafting DS , KEY & DNSKEY   resource records.

5:  A finally "Major  issues with standardization & adoption  between DNS providers"


A OpenDNS has supported  DNScurve for a while using their DNSCrypt. And support has dribble towards  the  MAC/linux/Windows OS clients  over the last 3years or so.


So what happens within DNS curve?

For DNScruve to be effective, we need to encrypt the DNS queries and the server must understands this query? Take this unsecured dns traffic for example;

The above are DNS traffic captured off the wire. Any hacker in the middle could intercept and or mangle the  request or response. 

Now with ECC cryptology, we can quick encode the request and response and any hacker in the middle would only see;

( DNS traffic using DNScurve against OpenDNS servers are  port 443/udp )

Since the ECC public keys are 255bit in length, this provides us with protection that exceeds the RSA typical 1024bit key sizes, which are commonly used with  DNSSEC.

reference
http://www.nsa.gov/business/programs/elliptic_curve.shtml



We also have the means to  enable DNScurve on our recursive  DNS servers to forward request  between non DNSCurve parties

reference
http://curvedns.on2it.net/

Now to install DNSCrypt  I will show you the typical layout under  MACOSX  & Lion.


1: grab the dmg file  http://www.opendns.com/technology/dnscrypt/

2: install the  DNScrypt into > Application folder

3: enable DNSCrypt  & OpenDNS as you primary resolver

And now your done. You can enable or disable it as required.


DNScurve has some negatives and that mainly due to the fact our   end-2-end encryption, is going to break  the firewalls abilities to inspect your dns traffic.  You could force inspection via a  proxy or a web-proxy and nail all of your clients behind the proxies. This would now require you to trust your  proxies.

And 2nd any web content filtering that  based around  DNS  lookup requests, would fail. So keep this in mind as you decide on on deploying  DNSCurve.

btw: this is a non-issues with DNSSEC

And lastly, OpendDNS uses udp/443 for it's services which may be filter  at a WiFi hotspot, but it will fallback to  port 53

More  information can be found here about DNScrypt

http://dnscrypt.org/

Ken Felix
Freelance Network/Security Engineer
kfelix ---at--- socpuppets-----d-o-t---com


   ^     ^
=( *  * )=
      @
    /     \

CCIE RS licking my wounds

My  2nd attempt went much better but I  still had issues with the t-shooting section of the lab.

My game plan was to be meticulous with all tickets and the resolution. It look's like I didn't followed this plan, but I was much happy with my  2nd attempt at RTP.

One area that I knew I failed in, pertains to  reviewing my completed tasks. As soon as I left the lab and gotten back to the Airport, I realize I missed some simple steps thru out the  t-shoot/configuration portions of the lab attempt.

I looking forwards for the next attempt probably later on in the year.

A former associate sent me a interesting link that talks about the CCIE process that I would like to share.


http://certcollection.org/forum/groups/


Ken Felix
Freelance Network/Security Engineer
kfelix ---at--- socpuppets ----d-o-t----com

T minus 12 hrs to showdown ( CCIE RS lab RTP )

Okay I'm in  RTP area  and relaxing for the big event tomorrow at 07:15 hours.  Temp was approx 90degs, but some dark clouds and a few  sprinkle cooled the air.


Here's the Kitt Creek   entrance and my study guide at Cisco Campus

Temp  ( 88deg F )

And finaly, the juice to keep me up if I get tired tomorrow in the lab from the shell gas station on Miami Rd Durnham

Wish me luck for tomorrow. I might walk up the street to Mez for Dinner.  The other location that had great plates is closed ( Page Rd Grill is the name of it )


Ken Felix Freelance Network/Security engineer
kfelix---at----socpuppets --d-o-t--com

ospf sham-links mpls vpnv4

In this blog we will look at the  ospf sham-links  & a backdoor  route between CEs. Here's the layout  in GNS3

• Okay the backup route are connected between fas0/1
• And CEs connects to PEs on fas0/0
• MPLS ldp is enabled on  both PEs between fas 0/1s

Okay so 1st here's the CE configs;



CE1


interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.1.0.1 255.255.255.0
 speed 100
 full-duplex
!
interface FastEthernet0/1  <---- backup route interface in area 0
 ip address 5.5.5.1 255.255.255.0
 speed 100
 full-duplex
!
router ospf 1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 5.5.5.0 0.0.0.255 area 0
 network 10.1.0.0 0.0.0.255 area 0
!
 
CE2

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.2.0.1 255.255.255.0
 speed 100
 full-duplex
!
interface FastEthernet0/1 <---- backup route interface in area 0
  ip address 5.5.5.2 255.255.255.0
 speed 100
 full-duplex
!
router ospf 1
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 5.5.5.0 0.0.0.255 area 0
 network 10.2.0.0 0.0.0.255 area 0



Okay that's straight forward and simple. The PEs are where the funs at.

PE1


!
!
ip vrf ce1
 rd 5706:1
 route-target export 5706:1
 route-target import 5706:1
!

interface Loopback7
 ip vrf forwarding ce1
 ip address 7.7.7.7 255.255.255.255
!
interface Loopback100
 ip address 100.100.100.1 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip vrf forwarding ce1
 ip address 10.1.0.2 255.255.255.0
 speed 100
 full-duplex
!
interface FastEthernet0/1
 ip address 9.9.9.1 255.255.255.0
 ip ospf 1 area 0
 speed 100
 full-duplex
 mpls ip
!
router ospf 11 vrf ce1   <--- notice ospf proc # ( I will explain this and the next line later )
 domain-id 0.0.0.12
 log-adjacency-changes
 area 0 sham-link 7.7.7.7 7.7.7.8 cost 10
 redistribute bgp 5706 metric 100 subnets route-map nosham
 network 10.1.0.0 0.0.0.255 area 0
!
router ospf 1
 log-adjacency-changes
!
router bgp 5706
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 100.100.100.2 remote-as 5706
 neighbor 100.100.100.2 update-source Loopback100
 !
 address-family vpnv4
  neighbor 100.100.100.2 activate
  neighbor 100.100.100.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf ce1
  redistribute ospf 11 vrf ce1
  no synchronization
  network 7.7.7.7 mask 255.255.255.255
 exit-address-family
!

!
ip access-list standard nosham
 deny   7.7.7.7
 deny   7.7.7.8
 permit any
!
route-map nosham permit 10
 description drop-sham-link-loop7
 match ip address nosham
!
!

and

PE2

!
ip vrf ce2
 rd 5706:1
 route-target export 5706:1
 route-target import 5706:1
!
!
interface Loopback7
 ip vrf forwarding ce2
 ip address 7.7.7.8 255.255.255.255
!
interface Loopback100
 ip address 100.100.100.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip vrf forwarding ce2
 ip address 10.2.0.2 255.255.255.0
 speed 100
 full-duplex
!
interface FastEthernet0/1
 ip address 9.9.9.2 255.255.255.0
 ip ospf 1 area 0
 speed 100
 full-duplex
 mpls ip
!
router ospf 12 vrf ce2  <--- notice ospf proc #
  log-adjacency-changes
 area 0 sham-link 7.7.7.8 7.7.7.7 cost 10
 redistribute bgp 5706 metric 100 subnets route-map nosham
 network 10.2.0.0 0.0.0.255 area 0
!
router ospf 1
 log-adjacency-changes
!
router bgp 5706
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 100.100.100.1 remote-as 5706
 neighbor 100.100.100.1 update-source Loopback100
 !
 address-family vpnv4
  neighbor 100.100.100.1 activate
  neighbor 100.100.100.1 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf ce2
  redistribute ospf 12 vrf ce2
  no synchronization
  network 7.7.7.8 mask 255.255.255.255
 exit-address-family
!
!
ip access-list standard nosham
 deny   7.7.7.7
 deny   7.7.7.8
 permit any
!
route-map nosham permit 10
 description drop-sham-link-loop7
 match ip address nosham
!
!

Okay looks complex?  Not at all.

The  vrf vpnv4 is simple ans straight MPLS. We enable our vrf interfaces and  routing for bring in our  customer prefixes via it's IGP ( ospf in this case )

We carry these routes via the  MPLS  cloud.


We next build a pair of loopbacks /32 on PE1 & 2

These are advertised  into BGP vrf ce1/ce2 and filter via nosham  route-maps from our  vrf CEs. And filter, from redistribution in the ospf process on #11 & #12 ( CE1 and CE2 respectively )


Finally we crafted the backup router interfaces on the 2 CEs and adjust the ospf cost to make this path less favorable. In this design, I need a cost of 14+ to enforce traffic over the MPLS backbone.

 In the end we want  Intra-Area routes represented over the MPLS-backbne.

( see the finally  route tables from the CEs prespective )

and a trace route to confirm;
( note: simulated a sham-link failure by shutting one of the PEs loopback#7 interface, to enforce the backup route )

Okay simple and straight forward.

Key take-ways;

• make sure you watch you configuration to limit the  sham-links networks into OSPF on all CEs
• if ospf process #s don't match adjust them with the ospf domain-id ( see my big note )
• adjust ospf cost on backup routes until you get the desired route

Ken Felix
Freelance Network & Security Engineer
kfelix  ------at----- socpuppets ---d---o---t---- com

            ^         ^
         (  @    @ )
-------------------------------

dump a packet on a cisco router

A neat trick that you can use  & if your in a bind.

                                                              Just take a dump !

                                                   Okay, not that kind of  dump!

You can craft a acl and debug that  acl with the keyword dump. Let's say you want to look at traffic to a single host and port 666/tcp


   config t

   !
   !
   !
   access-list 101 permit tcp any host 1.1.1.1 eq 666
   !
   !
   end


and finally

     debug ip packet detail 101 dump

     show log 

The output will be dump in a way similar to tcpdump and  the -A option.

e.g
*Mar  1 02:00:15.743: IP: s=10.0.0.2 (local), d=224.0.0.5 (FastEthernet0/0), len 76, sending broad/multicast, proto=89
47A00D50:                   45C0004C 03470000          E@.L.G..
47A00D60: 0159CB4B 0A000002 E0000005 0201002C  .YKK....`......,
47A00D70: 02020202 00000000 DE980000 00000000  ........^.......
47A00D80: 00000000 FFFFFF00 000A1201 00000028  ...............(
47A00D90: 0A000002 00000000 FFF60003 00010004  .........v......
47A00DA0: 00000001                             ....           
R2#
*Mar  1 02:00:25.743: IP: s=10.0.0.2 (local), d=224.0.0.5 (FastEthernet0/0), len 76, sending broad/multicast, proto=89
47A00350:                   45C0004C 03480000          E@.L.H..
47A00360: 0159CB4A 0A000002 E0000005 0201002C  .YKJ....`......,
47A00370: 02020202 00000000 DE980000 00000000  ........^.......
47A00380: 00000000 FFFFFF00 000A1201 00000028  ...............(
47A00390: 0A000002 00000000 FFF60003 00010004  .........v......
47A003A0: 00000001                             ....           
R2#
*Mar  1 02:00:35.743: IP: s=10.0.0.2 (local), d=224.0.0.5 (FastEthernet0/0), len 76, sending broad/multicast, proto=89
47A01110:                   45C0004C 03490000          E@.L.I..
47A01120: 0159CB49 0A000002 E0000005 0201002C  .YKI....`......,
47A01130: 02020202 00000000 DE980000 00000000  ........^.......
47A01140: 00000000 FFFFFF00 000A1201 00000028  ...............(
47A01150: 0A000002 00000000 FFF60003 00010004  .........v......
47A01160: 00000001                             ....           
R2#
*Mar  1 02:00:45.743: IP: s=10.0.0.2 (local), d=224.0.0.5 (FastEthernet0/0), len 76, sending broad/multicast, proto=89
47A01390:                   45C0004C 034A0000          E@.L.J..
47A013A0: 0159CB48 0A000002 E0000005 0201002C  .YKH....`......,
47A013B0: 02020202 00000000 DE980000 00000000  ........^.......
47A013C0: 00000000 FFFFFF00 000A1201 00000028  ...............(
47A013D0: 0A000002 00000000 FFF60003 00010004  .........v......
47A013E0: 00000001                             ....           
R2#


NOTE: The above is a simple ospf dump btw.


Just make sure  you  clear the debug when you done.  Key points;

• be specific with the ACL
• if your cpu is high, you probably want to avoid this
• term mon will dump to your screen

Ken Felix
Freelance Network & Security Engineer
kfelix  ---a--t-- socpuppets ---d---o--t--- com


    ^      ^
=( *     * )=
        O
       // \\

96hours and counting RTP CCIE/RS

I'm all ready for my official "2nd attempt" &  at the CCIE/RS lab.


I feel confident that I will do much better, and really hoping I'm going to pass on my 2nd attempt.

The 1st attempt , and with technical lab difficulties at my 2nd trip, gave me a lot of knowledge on what I need to work at & in ordering to  score the passing grade.

I've been reviewing my studies notes based on the cisco blueprint and objectives.  I've have been maintain theses note since Dec 2011, and adding to it,  as I found new and interesting things doing my  studies, personal labs, and the attempts.

One thing that's interesting and helpful that I want to share;

If you builds labs using GNS3 or real-gear, the problems you encounter in that buildout, only helps you more with your trouble-shooting knowledge

What this means;

Problems you created intentional or not, helps you  to trouble shoot them. It could be something like a simple typo, wrong interface, missing statement, or just configured wrong, etc.......


I'll give you a simple example,

A few days ago I was crafting a DHCP pool  ( something very  simple btw )  and inserted the wrong gateway. I spent  5-10mins scratching my head as to why my  dhcp-client was not reachable , until I slowed down and parsed  my config and found my error.

In all trouble-shooting process, 1> you need to see the problem ( the lab make it easy by telling you wants wrong ) and 2> then think of what could contribute to that problem. Most of this will come from "show  commands" and person experiences & encounters that you have part-taken of. And finally 3> insert the correction action to  fix the problem.

Always validate your work and make sure you meet the goal and requirement of the task.


A few friends and associates that I 've known for a decade + ( CCIEs and non ), has given  me some pointers over the last feew weeks.  And a  few of my former associates,  just went to the ccie lab in SJC & RTP, and where not successful. So that's been weighing on my mind for the last 3 weeks.

They are both  outstanding engineers ( Rick & Ed  you know who you  are :) ) and I'm sure they will get it on the next trip around

This trip  breakdowns for cost so far;

• 1,500 USD ( lab fee  actually it was voucher from my technical difficulties during trip#2 )
• 36 USD  ( enterprise car rental )
• 286 USD  ( iflyswa )
• 88 USD ( hotel stay wingate+durnham )

I'm figuring another 100USD for any misc stuff ( food, starbucks/dunkin donuts, red-bulls and parking garage,etc......).


There's a few decent eateries on page road near my hotel,  and I-expressway. So I plan on eating a good dinner on  Sunday when I do arrive.

Maybe at the Mez

http://www.mezdurham.com/

Or the other place directly down the street on the same side. They have some nice dishes, but slightly too much salt on the fries ( can't remember the name  tho but it's a red brick building directly across from the fedex  shipping center )


I also found a problem with one of my 1841ISR router, so I've been using a odd-ball  3550 for some L3 route injections in a few customs labs that I've crafted & that was able to keep me rolling for the last 3 weeks. I believe it's bad cookies or corrupt flash. If i can't fix it, I will be force to buy a another 1841 router.

So my  rack gear is down one 1841ISR at this time;

Current rack Gear inventory;

2x 3825ISR 15.1 ( various ) (  WIC-2T )  ( NAM )  (WIC-1DSU-T1 )
2x 1841ISR  12.4 advsecurity ( various ) (  WIC-2T ) (WIC-1DSU-T1 )
2x  3560  12.2.44 ( 2x GLC-SX-MM  + 2x  SFP-T transceivers )
1x 3350ISR   12.2-44.SE6
1x 3620    12.2 ipbase ( 1 WIC-2E )
1x ASA5505  9.1.1   ( not require for CCIE RS )
MacBook or MacBook Pro for GNS3 and console via zterm for any async  ( Snow Lepoard and Lion )


Also GNS3 was crashing my new Lion MacBook Pro,  so I had to delete the gsn3 ini file and rebuild all of my  GNS3 stuff.  I also lost most of my  custom GNS3 topologies and labs. ( over 30+ )


Here's the gns3 initialization file that you might need to delete if GNS3 has problems.
e.g

So that's the only way to  clear out all  gns3 initializations (unix  rm .gns3/gns3.ini )




btw, here's the GNS3 version I'm using now under macosx ;

http://www.gns3.net/

Outside of this, it has been  straight forward with/ 2-3hours  &  3-4 nights per week &  for the last  5 weeks. I 've been using the micronic trainingbooks, and mainly the  "t-shooting  section" and it's has been very helpful.

You can locate this study guides at the following links;

http://www.micronicstraining.com/product/rs-workbook-bundle-2/

I also been following  Laurent  CCIE trek  & as my motivation. You can read more about his journey  here;

http://aitaseller.wordpress.com/about/


For technologies covered over the last few weeks, and months, I've listed them below . I've  been refreshing myself since my current role has me doing little to no cisco activities ;

L3 redundancy gateway protocols
PVLANs
port-security 
EIGRP redistribute concepts and techniques
MPLS sham-links
Smarter ACL list crafting
ssh rotary
ip http server and authentication
ppp authentications 
ospf virtual-links
multicast t-shooting


So I feel very confident in the above technologies. I 'm also planning on trying somew new techniques to speed up the insertion of my configurations, by using the  windows notepad & crafting the relevant config for ALL actions in the configuration sections of the CCIE lab  and then pasting it in.

Maybe for example, I do all L3 interfaces  on the router objects and including the routing process and then dump it into router  and move on to the next, and then the next. 

Speed & accuracy is what's required to pass this exam.  Disabling logging to the console during the configuration, would also free up any output and clutter, keeping your cli clear and clean.

I even phantom building a quick alias-cmd set, but since I had a hard time remember my own aliases & rarely use them,. I figure I would drop that and not waste my time on alias.  How much time does a "show run interface "  vrs "srin"  gives you,  is disputable.

note: Anything that you can do, to  reduce you configuration time, can only help you later. It would give you more time to re-evaluate and for diagnostics.

Stay tune

 Ken Felix
 Freelance Network & Security Engineer
 kfelix -a--t- socpuppets ---d--o--t--- com

   ^      ^
=( *   * )=
      o 
     /  \
 

VRRP authentication issues ( cisco )

In this post I'm going to show you a interesting  md5 key issues with VRRP


Cisco supports a wide array of protocols that uses  text or md5 based authentication.

e.g
GLBP
LDP
RIPv2
BGP
OSPF
EIGRP
IS-IS

All of the above support some types of authentication.

In best common practices,  we want to use the same key-chain key ID for all authentications purporse, but some protocols allows for a slight degree of variance in  the key-chain id for expirations. VRRP is a different beast.Take this snapshot;

And on the 1.1.1.1  router we have the following key configured;

Notice the BADAUTHs ? Why is this so? Both routers have the keystring of cisclob for their  md5 key ?


Will here's the reason why; " with  VRRP  and authentication, it only supports key-id 0 & with any device using  just a md5 key-string under it's interface.

If you use any other key-id  and no matter if they all match, you will not  acquire authentication between  the VRRP members if one side uses the md5 key-string and the other side just a key-chain.


Once I configured the  key ID to be 0 , or configured both routers  vrrp auth type of "key-chain" , the BADAUTH will go away.

And when using  key-chains only, if the key IDs do not match, you will have problems.

So in this above example, we have a key-chain named vrrp, but the IDs do not match. One side ( r1 ) uses a key id of 1 and the other side a key id of 5.

By updating the key ID on the router#1 to match router#2, VRRP authentication will be established.

So to recap

1. VRRP authentication and use just a mix of a key-string for our vrrp interface and key-chain, requires the used of a key ID of 0
2. If you decided to use  key-chain for your vrrp interfaces, all key ID needs to  match.
3. The highest number key ID in key-chain will be  the key ID used
4. it probably  best to  not use md5 key-string option at all, under your vrrp interfaces ( imho )
5. GLBP authentication doesn't exhibit these issues, you either use key-string only or key-chain only thru out your AVG ( no mix and match )

 Ken Felix
Freelance Network/Security Engineer
kfelix ----at---- socpuppets ---d-o-t-- com

    ^       ^
=(  *    *  )
         o
      /      \

PPPoE cisco ( with dhcp assignments )

Here's a DHCP client enabled for PPPoE.

This is using GNS with the following code for both the client and server.

client#show version | incl ers
Cisco IOS Software, 3700 Software (C3745-SPSERVICESK9-M), Version 12.4(25b), RELEASE SOFTWARE (fc1)
ROM: 3700 Software (C3745-SPSERVICESK9-M), Version 12.4(25b), RELEASE SOFTWARE (fc1)
Importers, exporters, distributors and users are responsible for
client#

The  design;   R1= client  +  R2=Server

The configurations are provided in screen snap shots below.

Client

Server

Okay,  and don't forget the  username/password for local authentication on  the server or radius.

NOTE:  The lease time of 1 min , was set during my  "debug dhcp server" so I could monitor dhcp traffic from the client to server & the response.


Here's a debug of the  dhcpserver and the client;

And some more "show" commands;

Server

Client

So that's a wrap for how to deploy  dhcp addressing , and  with/pppoe clients on cisco IOS.

One more thing that should be pointed out;

"if your using a 1500byte interface mtu, you will need to adjust the tcp-mss size and/or mtu on the interfaces. PPPoE typically has at least 8 bytes overhead"

reference:

(MTU/MRU)

http://en.wikipedia.org/wiki/Point-to-point_protocol_over_Ethernet


So an adjustment to the above  configurations,  would  be to set the interface mtu ,  or deploy a  tcp adjust-mss,  if the interface mtu cmd is not  available. You can't really rely on path-mtu-discovery , since this relies on icmp unreachable messages, that could be filter or dropped by network devices.


 (modifications to my config for mtu or mss adjustments )
!
interface Dialer1
 ip address dhcp hostname client
 ip mtu 1492   <-------- example  using interface MTU size
 encapsulation ppp
 ip tcp adjust-mss 1452    <---------using a tcp mss interception
 dialer pool 1
 dialer-group 1
 ppp pap sent-username client password 0 cisco1
end


Ken Felix
kfelix --at-- socpuppets --insert-a-dot---- com
Freelance Network/Security Engineer

   ^          ^
=( @   @ )=
        *
       /  \

TCP blackholing ( try to hide your close ports )

In this blog we will look at the  TCP blackhole option.


In a typical systems, when we try to connect to a close port, a reset is given back to he client  under most Unixes.

It would be represented by the following;

A pcap dump would show the following;

You notice those Reset+ACKs being sent back to the client? That's what generates the immediated  "Unable to connect to remote host" message.

This is a tell-tale sign that the port is closed. But we have another way to mask this  give away , by using the tcp-blackhole

Take this display;

The "Trying" will continue until the application  quits & times out. And no resets are ever sent back to the client from the server that he/she was trying to access.

So how do you accomplish the above?

Easy,

We deploy tcp.blackholes, using system controls ( systcl ) and on the fly modify our kernel.

So this is how we hide our close ports & from outside  lookers :)

Apply a value of 2, will drop all  packets sent to a closed port.


Ken Felix
Freelance Network/Security Engineer
kfelix   -a-t     socpuppets   -d-o-t-   com

    ^      ^
= ( * @ ) =
       o
    /     \