NETWORK PRESENCE ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT
 


Search
display results
words begin  exact words  any words part 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [FW1] Multicast address



Here's the article:

Log Error: rule 0: Local interface address spoofing  
  
Check Point FireWall-1,   Gateway Configurations 
for version: 4.1 SP2  And Later  
  
last update: 12/01/2000 10:16:46  
This error message started showing up on 4.1 SP2 and 4.0 SP5 hotfix
installations when used with VRRP.

This is a new security feature of FireWall-1 4.1 SP2 and 4.0 SP5 hotfix that
was included as part of the fixes for the issues announced at BlackHat 2000.
FireWall-1 now drops any packet it receives with a source IP address that
belongs to one of it's interfaces, which includes VRRP IP address. This
happens regardless of whether or not you configure anti-spoofing on your
interfaces. There are three possible reasons you may be experiencing this:

1. Using a VRRP IP in a Destination Static NAT, which is actually the most
common. This means the IP address you are using in a Destination Static NAT
is actually an IP address backed up by VRRP. To resolve the issue, use
proxy-only ARPs using the VRRP MAC instead of backing up these IPs with
VRRP. Note that in some switched configuration, this may not work correctly
without disabling spanning tree or MAC address caching. In this case, use
the resolution documented below.

2. You have two interfaces configured on logically different networks (say
192.168.1.0/24 and 192.168.2.0/24), but connected to the same hub or VLAN.
To resolve the problem, configure one of the physical interfaces with IP
addresses on both networks (say 192.168.1.1 and 192.168.2.1). If
anti-spoofing is used in FireWall-1, you will need to make configuration
changes accordingly.

3. Customers running VRRP v2 configurations (not Monitored Circuits) may
also experience problems. A customer reported these error messages in this
configuration. This specific problem should be resolved with IPSO 3.3 and
FireWall-1 4.1 SP2.  

SOLUTION  
To disable this new feature entirely, use the modzap utility in Resolution
1261 to disable this feature in the FireWall-1 Kernel Module and reboot:

modzap _fw_local_interface_anti_spoofing $FWDIR/boot/modules/fwmod.o 0x0
 

-----Original Message-----
From: Tim Holman [mailto:[email protected]]
Sent: 18 April 2001 15:27
To: Francisco Cabral; Fw-1-Mailinglist (E-mail)
Subject: Re: [FW1] Multicast address


Same VLAN for both interfaces, otherwise multicasts won't get through.
I don't have access to the KB at the moment, so can't check the article.
You don't want to add other IPs to your interfaces - remember that
Checkpoint only supports ONE external interface.
Is there any way you can send me screendumps of your mc configuration of
both machines ?

Tim

----- Original Message -----
From: Francisco Cabral <[email protected]>
To: 'Tim Holman' <[email protected]>; Fw-1-Mailinglist (E-mail)
<[email protected]>
Sent: 18 April 2001 13:24
Subject: RE: [FW1] Multicast address


> I think I found the problem. Take a look at Nokia Resolution id 3463 on
> their knowledge base, specifically at point 2.
>
> But now the problem is : how can you add multiple IPs on different
networks
> to the same interface? Tried through Voyager but only to get an error that
> the network was already defined on another interface.
>
> How's your setup? Do u use different VLANS for each interface?
>
> Francisco
>
> -----Original Message-----
> From: Tim Holman [mailto:[email protected]]
> Sent: 18 April 2001 14:12
> To: Francisco Cabral; Fw-1-Mailinglist (E-mail)
> Subject: Re: [FW1] Multicast address
>
>
> When you created the VRRP Multicast network object, did you use 224.0.0.18
> and 255.255.255.255 ?
> Have you setup an IGMP and VRRP rule ?
> Set one up with the source as 'firewall-1 + firewall 2', the destination
as
> 'firewall-1 + firewall 2', service VRRP (manually define this service with
> Match.. ip_p=112) AND IGMP, Accept, Log (although you'll probably want to
> skip the logs after a while).
> Check in your mc configuration that you're monitoring eth2 from the
circuit
> for eth1, and eth1 for the circuit for eth2.
> Something's not quite right as you shouldn't get these errors.
>
> Tim
>
>
> ----- Original Message -----
> From: Francisco Cabral <[email protected]>
> To: 'Tim Holman' <[email protected]>; Fw-1-Mailinglist (E-mail)
> <[email protected]>
> Sent: 18 April 2001 12:15
> Subject: RE: [FW1] Multicast address
>
>
> > The HA is setup to monitor all the FW interfaces except the Heartbeat
link
> > using monitored circuits.
> > The funny thing is that I'm getting drops, when I look at the logs, from
:
> >
> > Origin Source Destination
> > Services
> >
> > Public IP FW Master Any of the FW interfaces 224.0.0.18
> > 38401
> >
> > but from the slave I'm getting accepts:
> >
> > Origin Source Destination
> > Services
> >
> > Public IP FW Slave Any of the FW interfaces 224.0.0.18
> > 38401
> >
> >
> > -----Original Message-----
> > From: Tim Holman [mailto:[email protected]]
> > Sent: 18 April 2001 11:26
> > To: Francisco Cabral; Fw-1-Mailinglist (E-mail)
> > Subject: Re: [FW1] Multicast address
> >
> >
> > If there's no NAT in place, then public addresses should never make it
to
> > your LAN.
> > Have you allowed IGMP and VRRP (create the service manually) between the
> > firewalls ?
> > Have you setup monitored circuits with the Nokias ?
> > Could you post up a sample log message ?
> >
> > Cheers,
> >
> > Tim
> >
> >
> >
> >
> > ----- Original Message -----
> > From: Francisco Cabral <[email protected]>
> > To: 'Tim Holman' <[email protected]>; Fw-1-Mailinglist (E-mail)
> > <[email protected]>
> > Sent: 18 April 2001 08:42
> > Subject: RE: [FW1] Multicast address
> >
> >
> > > That's all done initially.
> > >
> > > I understand the need to monitor the FW interfaces but I would like
that
> > to
> > > be log-silent.
> > > Apparently, you managed to do it.
> > >
> > > When I look at the logs, I can see effectily that, through the LAN
> > > interface, packets are coming out with the public IP of the FW.
> > > There's no NAT defined for the FW IPs.
> > >
> > > Can anyone point me to an article explaining how multicast works so
that
> I
> > > can assess if this is a Nokia or a IP "feature"?
> > >
> > > Francisco
> > >
> > > -----Original Message-----
> > > From: Tim Holman [mailto:[email protected]]
> > > Sent: 17 April 2001 19:21
> > > To: Francisco Cabral; Fw-1-Mailinglist (E-mail)
> > > Subject: Re: [FW1] Multicast address
> > >
> > >
> > > What do your anti-spoofing rules say ?
> > > Setup the external interface to Others, the sync link to This Net, and
> the
> > > internal interface to Others+, adding a group with all the public IP
> > > addresses you're using for NAT.
> > > Do this for both firewalls, as this info is not replicated.
> > > If you're using 'Specific', then add the VRRP multicast object to the
> > group,
> > > but I've found the above formula works just as well.
> > >
> > > Tim
> > >
> > > ----- Original Message -----
> > > From: Francisco Cabral <[email protected]>
> > > To: Fw-1-Mailinglist (E-mail)
> > <[email protected]>
> > > Sent: 11 April 2001 11:02
> > > Subject: [FW1] Multicast address
> > >
> > >
> > > >
> > > > Hi,
> > > >
> > > > Each day, my FW logs get huge with the VRRP multicast address
entries
> > with
> > > > the reason of "address spoofing". Could the reason be that all the
FW
> > > > interfaces go into a hub (for testing)? Is there a way of not
logging
> > > these
> > > > packets? Thanks.
> > > >
> > > > Regards,
> > > >
> > > > Francisco Cabral
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
============================================================================
> > > ====
> > > >      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
================================================================================



 
----------------------------------

ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT SITE MAP LEGAL
   All contents © 2004 Network Presence, LLC. All rights reserved.