Shane, Your explanation of the flip-flopping of MAC address-to-VIP mapping is right. If that's working fine, then there is possibly a NAT issue.
The problem you are experiencing is strange. That should not be happenning. I would re-audit the net config and the Dashboard config, paying close attention to interfaces settings and Natted objects. The standby module is being hide-Natted behind the VIP, even though it has a physical IP on the external network. That sounds like it is sourcing from its real private IP and you have a network object that hide-Nats that subnet behind the VIP. You can try to create a manual NAT rule to disable NAT when the cluster sources to any nets that are not yours. You should not have to do this normally, but that may tell you if you have a misconfigured object or even a corrupt object somewhere in the database. What IP are you using in the general properties of the cluster object... internal or external? That object is not Natted, is it? Are ther any objects that may have an IP of the firewall (any i/f) that may also be natted? You can also try this, as a second-to-last resort... Delete the cluster object and the fw module objects, rebuild them, re-SIC, re-install policy, and try again. Let me know. Neil Delacruz On 1/17/06, Shane Presley <[EMAIL PROTECTED]> wrote: > > Hi Neil, > > I think we're on the same page, but the problem still exists. > > First, I completely agree about CCP and using broadcast. I have my > cluster members set to use broadcast. > > I understand you're explanation of the GARPs. But my understanding of > the IP addresses is different from what you said. It uses a Virtual > IP for the cluster, it's just that the MAC associated with that VIP > will float between the primary and standby during failovers. So > looking at our internal-facing interface, if firewall1 is 10.1.1.1 and > firewall2 is 10.1.1.2, and the ClusterXL VIP is 10.1.1.3. During > normal operation the MAC for 10.1.1.3 will be the physical interface > of 10.1.1.1. And during a failover, firewall2 issues a GARP and the > MAC for 10.1.1.3 becomes the MAC of the physical interface for > firewall2, correct? > > Anyway, that works perfectly for routing through the firewalls. The > problem is when firewall2 wants to source a packet. Let's say I log > on to firewall2, and issue an nslookup. I snoop the interface. I see > DNS traffic with a source of 10.1.1.3 heading for our DNS server. So > the firewall software must have translated the source to be 10.1.1.3, > instead of the physical NIC of 10.1.1.2. (There are no NAT rules for > this, so I must assume ClusterXL is doing it). If I do that same > nslookup and snoop with the firewall off (cpstop), it makes the > request from 10.1.1.2. So the problem is that when firewall2 sources > the packet from 10.1.1.3, and firewall1 is currently answering for > that, you never get a session (DNS traffic goes out, no replies). > > Does that make sense? > > Thanks for the help... > Shane > > > > On 1/17/06, fwguru <[EMAIL PROTECTED]> wrote: > > Shane, > > > > Something here does not make sense. You may need to audit your config > to > > see if you have a config error. I would start by checking the ARP table > of > > your upstream router/switch to see what it sees. > > > > CXL in New Mode uses real IP addresses. GARPs are sent to upstream > > router/switch to tell it which is the active member. The upstream > router > > will see the VIP tied to the MAC of the active's interface (VIP = Active > > MAC). The standby firewall acts as just another node behind the router. > > When a failure occurs, a GARP is sent to make the standby's MAC = the > VIP > > MAC. > > > > Not sure what OS you are running or if you are using CCP (cluster > control > > proto) with in multicast (default) or broadcast mode. Re-check your > config. > > Also check the contents of the $FWDIR/boot/ha_boot.conf. What is the > > ccp_mode set to? If it is multicast, try changing the CCP mode to > broadcast > > using this command on both of the firewalls: > > > > cphaconf set_ccp broadcast > > > > This command will survive a reboot, but you dont need to reboot or > > cprestart. > > > > Check the ARP cache of the upstream router. You should see the real IPs > of > > each firewall with its real MAC addresses in b-cast mode. You will also > see > > that the VIP is tied to the active member's MAC. > > > > I prefer using CCP broadcast in HA mode, since all upstream > routers/switches > > will know how to handle "real" unicast MAC addresses. > > > > By the way, CXL works just fine on Splat, and CXL for HA does not > require an > > additional CXL license. Not sure how Nokia Clustering works, but if a > CP > > critical process fails while all interfaces are "up" will Nokia > Clustering > > failover? > > > > I hope this sheds some light on your situation. > > > > > > Neil Delacruz > > > > ================================================= > 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] > ================================================= > ================================================= 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] =================================================
