Sergio, Based off your description, it appears the problems are coming off how SMC is 'hide-natt'd. Tweaking 'hosts' file anyways is not going to help nor would it help tweaking the 'masters' file. The $FWDIR/conf/masters file is auto-generated once SIC is established and policy pushed depending upon what you have on the fw modules 'log and masters' tab under 'masters' and 'log servers'. The only way you should and you must make any manual changes to the 'masters' file is when you have 'masters' and 'log server' set to 'Use local definitions for masters/log servers'...........otherwise, you may tweak it but in fact next time you push the policy (or as you said upon reboot, when the policy is fetched), your manual changes would be overridden.
The best solution that may work in your environment, with SMC and Firewall on the same network internally (if I understood it correctly), is to use 'Local definitions for Log Servers', push the policy and then edit the $FWDIR/conf/masters file and under "Logging' section just put in the IP address of the SMC defined in the general tab of the object in SmartDashboard. hth, Rajeev On 7/21/07, Sergio Alvarez <[EMAIL PROTECTED]> wrote:
Hello guys, Yesterday I gave my customer a visit to work on this issue and after hours of troubleshooting, I finally got it resolved although I'm not quite sure why my solution worked, so I'm wondering if someone can help me a bit with that and in that way I might be able to polish things a little. For starters, the environment had changed from what I had seen before, I don't want to get into details because it will make this posting even longer than it will be already, but basically now the SmartCenter didn't need to go through the original cluster to get to the new remote Nokia (from which we were not getting logs), now it was going through a dedicated line and both the SMC and the internal interface of the remote box had IPs in the same IP range. So starting from there we could rule out any relevance of NAT. I confirmed SIC was working fine between the remote box and the SMC, it as possible to get a policy installed, SV Monitor showed the remote box as OK and we were even getting alerts related with that box for example when bringing the policy down on it with "fw unloadlocal", but still not logs in the SV Tracker from it. I first tried the "fw fetch" command from the remote host and it was able to get connected and pull the policy from the SMC (which confirmed there were no connectivity issues), although I did that pointing to the IP of the SMC. When I tried it using the SMC hostname, it just said "fetching policy from <SMC_hostmane>" and then jumped right back to the prompt without showing anything else. It was clear it had not fetched anything, but why wasn't it giving any errors? I checked the $FWDIR/conf/masters file and it in fact showed the SMC hostname for "policy", "log" and "alert", so I started to think it had something to do with the "resolution" of that name. An obvious solution would be to change the masters file to point to the IP of the SMC instead of its hostname, but I had tried that in the past working on a different deployment and had found out the system changes it right back the way it was after a reboot, so I thought I could trick it by using some other object with the same IP of the SMC, as the log server for that remote gateway and that solved the problem. Basically I created a new Check Point host object, used the same IP of the SMC on it and selected just the "log server" in the list of Check Point products, then in the remote gateway object, went to the "logs and masters" sections and replaced the SMC for the new object as the log and alert server. Logs started to show in SV Tracker right after installing the policy on that box. The down side of this is the fact that SV Monitor shows an extra Check Point host that always has "bad reply" in the status with an ugly red x that catches the eye of anyone who sees it, which causes a lot of concerned faces and "what is that" questions. I'd like to get rid of that for cosmetic reasons (I'm sure you guys understand me), so can anybody help me understand why this thing worked this way? The only difference between the SMC and the new logserver object, besides obviously that one has the SmartCenter and the other doesn't, is the fact that this SMC has a "hide NAT - hide behind gateway interface" configured in the NAT tab and the logserver has nothing configured for NAT. I would say NAT has nothing to do with this as it should only apply when traffic traverses a firewall module, but I just can't think of anything else. BTW, we cannot disable NAT for the SMC, because of some other things going on that I would rather avoid explaining here. I would really appreciate any ideas about this. Thanks in advance. Regards On 7/19/07, Sergio Alvarez <[EMAIL PROTECTED]> wrote: > > Thanks a lot for all your input guys. > > I still haven't had the chance to get my hands on those boxes, that was > supposed to happen today, but my customer called to cancel and it will be > tomorrow afternoon. > > My customer deployed the remote Nokia on his own and basically all the > boxes involved (local Cluster, SMC and remote Nokia) are located within a > large WAN, so there should be no NAT required for the remote Nokia to talk > to the SMC as the network should be able to route traffic destined to the > real IP of that machine. Furthermore, I mentioned we are in fact seeing > TCP/257 traffic sourced on the Remote Nokia and destined to the SMC, on the > logs generated by the Cluster and those connections appear as accepted, so > that means a couple of things: > > 1. The Remote Nokia is in fact sending logs > 2. The traffic is being routed properly by the WAN as it is reaching the > cluster that lays right in front of the SMC > > Tomorrow I will check if NAT rules exist for the SMC and if fw monitor on > the SMC show any traffic coming from the remote Nokia and start from there. > > Several of your suggestions will be very useful during my troubleshooting > session tomorrow, so I really appreciate them. > > I'll let you know what happens. > > Regards > > > > On 7/19/07, Rajeev Gupta <[EMAIL PROTECTED]> wrote: > > > > I would start like this: > > > > Do a 'netstat -an | grep 257', for example, to see your module/s > > connection > > status - is it established to the SMC IP or what??? > > > > Second debug 'fwd' on both the SMC and FW module 'fw debug fwd on' - > > leave > > it on for a minute or two to capture data and look through > > '$FWDIR/log/fwd.elg' files on both SMC and the Module/s. > > > > The above two should tell you quite a story to move further w/ > > appropriate > > steps logically. If you so wish, you can post your netstat output and/or > > > > debug output - I do not mind it offline if you so wish. > > > > hth, > > Rajeev > > > > On 7/18/07, Sergio Alvarez <[EMAIL PROTECTED]> wrote: > > > > > > Hello, > > > > > > We have a deployment with a SmartCenter (SMC) over SPLAT, a couple of > > > Nokia > > > boxes running IPSO Clustering in front of that SMC, and an extra fw > > module > > > also running over Nokia in a remote location. > > > > > > Everything runs Check Point NGX R60 HFA05. > > > > > > The remote fw module is new and we have SIC working properly, it is > > > possible > > > to install the policy on it with no issues and we see traffic in > > TCP/257 > > > (FW1_log) passing though the Cluster with the remote module as the > > source > > > and the SMC as the destination, but those logs are not shown in the SV > > > Tracker. > > > > > > There is nothing between the Cluster and the SmartCenter so we are > > sure > > > this > > > traffic must be reaching the SMC network, so do you guys know of any > > > reason > > > why logs could reach a SMC but not be displayed in the SV Tracker??? > > > > > > We will do extra tests tomorrow with me on site, but I just can't > > think > > > what > > > could be wrong.... > > > > > > Any assistance with this issue will be very appreciated. > > > > > > Regards > > > > > > -- > > > Sergio Alvarez > > > (506)8301342 > > > > > > ================================================= > > > 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] > > ================================================= > > > > > > -- > Sergio Alvarez > (506)8301342 -- Sergio Alvarez (506)8301342 ================================================= 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] =================================================
