Re: [FW1] Monitored Circuit Configuration on Nokia

[CryptoTech <cryptotech@FW1-NOSPAMgmx.de>]

Mark,
Please take no offense, but if it is that easy, then I would rather use a rainfinity
or stonebeat solution.

Mark Hall/St Louis/IBM wrote:

> > - -----Original Message-----
> > From: owner-fw-1-mailinglist@lists.us.checkpoint.com
> > [mailto:owner-fw-1-mailinglist@lists.us.checkpoint.com]On Behalf Of Mal
> > Herring
> > Sent: Thursday, February 15, 2001 9:31 AM
> > To: 'Tim Anderson'; 'fw-1-mailinglist@lists.us.checkpoint.com'
> > Subject: RE: [FW1] Nokia vs. NT
>
> > From what I know - No Load balancing unless you configure ½ hosts on one
> and
> > other ½ to other fw, and fail-over with VRRP has caused me load of grief
> so
> > I am looking to use the Monitored Circuit solution - should anyone have
> any
> > knowledge on this - please mail me.
>
> > regards
>
> > mal
>
> Well, this isn't an absolute guide, but a basic so you can get monitored
> circuit working correctly.  This example assumes that you're using two
> firewalls that are mirror images of each other...:
>
> 1) Count the # of interfaces with VIRTUAL addresses that you plan to use
> (i'll use 6 for our example).  Make sure your delta is higher than this
> number.  I'm going to assume you are using fewer than 14 interfaces. ;-)
> 2) For each interface with a VIRTUAL address, check the 'monitored
> circuit' radio buton, and then apply the page.
> 3) Define a router ID for each virtual address.  Note:  This ID *MUST* be
> unique per network segment.  This router id is used to generate the MAC
> address for the virtual address.  This address will be 0:0:5e:0:1:xx where
> xx is the hex value of the router ID#.  This is WHY you can't have more
> than 1 set of firewalls sharing a VRID on a single network segment,
> otherwise they'll BOTH try to pick up and forward the packets.  In fact,
> we found a problem when we shared a VRID# that forwarding didn't work
> correctly, and two firewalls on the same management station both received
> the same packet - one accepted, one dropped.  got confusing in the logs.
> ;-)
> 4) Once this is done, simply multiply your # of interfaces by something
> like 15 and add some number.  This also must be less than 255 (it's a one
> byte field).  I recommend adding something like 15.  With the 6 interface
> example, my primary's priority will be 100.  Fill out the field per
> interface with the virtual address, the primary's priority, and a hello
> interval of 1 (failover within 3 missed hellos, or 3 seconds).  For the
> secondary, its priority should be somewhat less than the primary's, and
> higher than a single interface's delta.  Remember the multiply by 15
> earlier?  That's the delta we'll use, and the priority for the secondary
> should be higher than this, let's use 95.  If you're using more than 15
> interfaces, 15*15 is higher than 255, so you may need to add a 'negative'
> number to drop the highest end to less than 255.  What this will do when
> they all subtract from your priority I don't know. =-)
> 5) for each monitored interface, let's use a delta of 15, and select one
> of the other monitored interfaces (i.e. interfaces 4 on 3, 3 on 4, 3 on 5,
> 3 on 6, 3 on 7, 3 on 8), then apply.  For the secondary, you cannot use 0
> as a delta, use 1, but do the same thing.
> 6) apply each other monitored interface to each monitored interface with
> the appropriate deltas.  When any interface on the firewall goes down,
> since every other interface monitors the one that went down, they'll
> cascade shutdown, meaning NONE of your monitored interfaces will be 'up'
> in the priority calculation, resulting in a value of 10.  Then, the
> secondary will have a higher priority, and will take over the virtual
> addresses.  This is how it should work.  So interface 3 should end up
> monitoring 4, 5, 6, 7, 8.  and so on.
> Don't forget to add a firewall rule to allow multicast traffic from all
> physical and virtual addresses to talk to 224.0.0.18 with a service type
> other named VRRP with a match of:  ip_p=0x70.
> 7) Then click on the "VRRP monitor" link at the bottom of the VRRP page.
> The primary should be ALL master, and the secondary should be ALL backup.
> If any don't match correctly on the secondary, those interfaces can't
> communicate.  Try pinging the physicals between them to make sure they
> work.  If it all works, you can 'bounce' the nokia, and the other one will
> pick it up in 3 seconds.  If you IF down an interface, it will fail all
> over to the other machine.  We've had some problems with FW1 working right
> after doing this though.
>
> Oh, one other important thing, remember you CANNOT ping or talk to the
> virtual at all, but you will see its entry in your ARP tables on other
> systems, and if it's working right, the packets will pass through.  i.e.
> you can ping through it, telnet through it, whatever your rules allow.
>
> Hope this helps. :-)
>
> Mark Hall    <><
> CheckPoint Certified Security Engineer
> Certified AIX System Administrator
>
> Mailstop S306 2182
> IBM Global Services - Network Services
> 325 J.S. McDonnell Boulevard
> Hazelwood, MO 63042
> Voice:Fax:>
> This message contains an average of 73% post-consumer electrons.
>
> ================================================================================
>      To unsubscribe from this mailing list, please see the instructions at
>                http://www.checkpoint.com/services/mailing.html
> ================================================================================



================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================