Eric, Maybe you should try to run tcpdump with the -e parameter to see the MAC address of the device which actually sends the suspicious packet you mention. What you see in the Origin column of the log example you sent, doesn't always mean that this packet is actually coming from the active member of the cluster. It could be a problem in the switches (if, for example, they are also clustered and some small config issue has been overlooked) which causes them to send the packets which originated from the active member back to the cluster IP address. In your case, I wouldn't be surprised if you see outputs not exactly but similar to below when you ping the cluster IP from the Internet router:
<time> <MAC-of-switch> <MAC-active-node> ip 74: <router-ip> -> <cluster-ip>: icmp: echo request <time> <MAC-active-node> <MAC-of-switch> ip 74: <act-node-ip> -> <router-ip>: icmp: echo reply <time> <MAC-of-switch> <MAC-active-node> ip 74: <act-node-ip> -> <router-ip>: icmp: echo reply In this case, line 3 is the reason of logs you see (for some erroneous reason, switch is sending back the packet). FW-1 doesn't like packets where the src ip belongs to one of its interfaces but the src MAC does not belong to its Mac address (which is called local interface address spoofing and addresses the situation when a bad guy in the LAN plays the role of FW-1) > -----Original Message----- > From: Mailing list for discussion of Firewall-1 [mailto:FW-1- > [EMAIL PROTECTED] On Behalf Of Eric Janz > Sent: Monday, April 21, 2008 10:26 AM > To: [email protected] > Subject: Re: [FW-1] Secureclients are failing intermitently after > upgrading an Nokia Cluster to NGX R65 ( local interface address > spoofing ) > > Good Morning ! > > Well, as I thought on Friday, the problem still persists. After the > traffic was again balanced on both cluster nodes, the Securemote > connections fail again with "local address spoofing" and we get entries > in > the log like the following one: > > Number: 28864 > Date: 21Apr2008 > Time: 8:04:28 > Product: VPN-1 Power/UTM > Interface: <external-interface> > Origin: <cluster-node-1-external-ip> > Type: Alert > Action: Drop > Protocol: udp > Service: VPN1_IPSEC_encapsulation (2746) > Source: <cluster-external-ip> > Destination: <securemote-client-public-ip> > Source Port: VPN1_IPSEC_encapsulation > Information: message_info: Local interface address > spoofing > SmartDefense Profile: Default_Protection > Policy Info: Policy Name: <Policy> > Created at: Fri Apr 18 17:45:09 > 2008 > Installed from: <Smartcenter> > > > ¿ Any idea about this ? ¿ Did somebody see the same strange behaviour ? > > Thanks again for any advice, > Kind Regards, > Eric Janz > > > Mailing list for discussion of Firewall-1 > <[email protected]> wrote on 18/04/2008 > 19:03:33: > > > Hi again, > > > > just a comment about this, the NTP setup on the Nokia Cluster is set > in > a > > manner so that the sync cluster ip address's serve as NTP Master. I > found > > a Known Limitation in the IPSO 4.2 Build 78 Release Notes which > states > > that in this version there is some kind of problem due to that it is > not > > > recommended to use the cluster members as NTP Masters even not using > the > > > cluster sync ip's. In fact, the cluster nodes local time differes one > > second ¿ could this be a reason for the "local interface address > spoofing" > > ? > > > > <--- snip "Getting Started and Release Notes for IPSO 4.2 ( Build 078 > ), > > > page 145 ---> > > Do Not Configure Nodes as NTP Server <PR 52178> > > If you enable VRRP or clustering, do not use any of the nodes > as > > > an NTP > > server. An issue with xntpd can cause the node to enter into > a > > continuous loop > > of leave and join mode, thus disrupting traffic. You can > still > > configure nodes > > to be NTP clients. > > <--- snip ---> > > > > By now I setup an external NTP server and now the local time of the > > cluster members is sync'd and the VPN Clients are also working. Both > > cluster members leaved the cluster and rejoined, 98% of the actual > > connections are assigned to the master node and all new connections > are > > going to the member node ( I am using static work assigment ) ¿ Maybe > the > > VPN connections are only working at this moment because every new > > connection is going through the same node ? > > > > What do you think ? > > > > Well, thanks again in advance, > > I will update this thread with the final results, > > > > > > Kind Regards, > > Eric Janz > > > > > > > > > > Eric Janz <[EMAIL PROTECTED]> > > Enviado por: Mailing list for discussion of Firewall-1 > > <[email protected]> > > 18/04/2008 14:07 > > Por favor, responda a > > Mailing list for discussion of Firewall-1 > > <[email protected]> > > > > > > Para > > [email protected] > > cc > > > > Asunto > > [FW-1] Secureclients are failing intermitently after upgrading an > Nokia > > Cluster to NGX R65 ( local interface address spoofing ) > > > > > > > > > > > > > > Hi Everybody, > > > > We had a 2 nodes Nokia IP380 Cluster with IPSO 3.8 and Checkpoint NGX > R60 > > and upgraded it last week to a 2 nodes Nokia IP690 Cluster with IPSO > 4.2 > > > Build 078 and have installed Checkpoint VPN-1 Power NGX R65 without > HFA's. > > > > The nokia cluster is working in forwarding mode and static work > assignment > > > > with the failure interval set to 5000ms. The cpu and memory > utilization > is > > > > normal. At the Checkpoint level we are using Nokia IP Clustering Load > > Sharing. We have remote clients which are connecting with Secure > Client > > using different versions ( R55, R56, R60 ) in office mode and they > get > IPs > > > > assigned from our central dhcp server. The office mode antispoofing > is > on > > and configured with the network range that can be assigned by the > dhcp > > server and this network is not used locally and always gets routed > through > > > > the Firewall. > > > > Everything went fine, we first upgraded our Smartcenter and then > changed > > > the gateways, but a few days ago we noticed that the VPN connections > fail > > "sometimes". At the user laptops we see that the tunnel test is > failing > > but it says that the connection was established successfully. > > > > I have read a lot of SK's and googled around "local interface address > > spoofing" and "tunnel test failure" without a lot of success and > after > > testing a lot of options in the gateway configuration (MEP on/off, > Dynamic > > > > Gateway Address Resolution vs Gateway Address Resolution from > topology, > > etc ) I found that the only way to get the client vpn connections to > work > > is removing one node from the cluster leaving the other one alone. > > > > At Smartview Tracker I found log entries that state that there is > "local > > > interface address spoofing" and it seems to me that this is happening > when > > > > the client establishes the VPN through one gateway but the response > is > > trying to get out the other one ¿ is that a possible problem ? ¿ > shouldnt > > the connections be sincronized between the cluster members ? > > > > Number: 13474 > > Date: 18Apr2008 > > Time: 13:01:46 > > Product: VPN-1 Power/UTM > > Interface: eth-s1p1c1 > > Origin: <cluster-node-2-external-ip> > > Type: Alert > > Action: Drop > > Protocol: udp > > Service: 10366 > > Source: <cluster-external-ip> > > Destination: <remote-client-public-dsl-ip> > > Source Port: IKE_NAT_TRAVERSAL > > Information: message_info: Local interface address > > spoofing > > SmartDefense Profile: Default_Protection > > Policy Info: Policy Name: policy1 > > Created at: Fri Apr 18 > 12:50:08 > > 2008 > > Installed from: smartcenter > > > > > > When this is happening, I try to ping from the remote client a local > pc > > and I can see with a tcpdump that the packets are arriving to the > local > pc > > > > with the office mode remote source ip from the remote client and that > the > > local pc is responding. This response arrives to the firewall and > gets > > dropped due to the local interface address spoofing ¿? > > > > > > Thanks a lot in advance for any advice, > > Kind Regards, > > Eric Janz > > > > > > Scanned by Check Point Total Security Gateway. ================================================= To set vacation, Out-Of-Office, or away messages, send an email to [EMAIL PROTECTED] in the BODY of the email add: set fw-1-mailinglist nomail ================================================= To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================= If you have any questions on how to change your subscription options, email [EMAIL PROTECTED] =================================================
