Peter,

If the NAT is occurring naturally (ie on a non-Check Point device en-route) 
then no - but you DO need to make sure that you are NOT accidentally applying 
NAT rules on that gateway that could affect things.

More likely is probably the anti-spoofing applied to the interface that the 
management connection is arriving on - zdebug will probably help you determine 
that. 

Is your source address (ie the management server) getting NAT'd ?  If it is, 
then this is going to get messy, especially if that SmartCenter manages more 
than this one gateway pair.    The firewall will assume that it's management 
server is on the IP address that is shown in the General IP address on the 
SmartCenter object.  Until you install policy, the firewalls will accept 
control from ANY  management server with a valid SIC, but once you push the 
policy down, part of the information handed to the firewalls is the specific IP 
addresses of the management and log servers.

What this would mean  is that if your management server is on 10.10.10.10 
physically, but the en-route NAT changes this to 20.20.20.20, the GENERAL IP 
address of the management server will need to be configured as 20.20.20.20 in 
order for it to work properly.  If, however, you have a second pair of 
firewalls that see the management server properly as it's un-NAT'd address 
(10.10.10.10) then you will have issues if you start changing the General IP 
address.

If you are using SmartCenter, you should be able to open the topology tab of 
the management server object and create one entry for the real IP address (eth0 
- 10.10.10.10) and then a second entry (eth1 - 20.20.20.20).  Depending on the 
version (and this really does behave differently in different releases), you 
should then be able to push policy and the gateway will accept connections from 
either IP address. If this is the only gateway you are managing, you can then 
set the General IP address to the 20.20.20.20 NAT address and job done.  If you 
have other gateways too then you probably cannot change the general address, so 
you may continue to see logging issues because the firewall will continue to 
try to log to the address in the General tab.  You may be able to overcome this 
using something as simple as a forced static host route for the general IP 
address via the NATting router, or you may need to create a separate "dummy" 
log server object and use that instead of the Sma!
 rtCenter in the logs and masters section as the log server of choice.

Or you can work out a way to eliminate the need for NAT in the first place 
(like moving the Smart Centre to another place in the network) :)

Best regards,


Steve
Security is a process, not a product.
 

-----Original Message-----
From: Mailing list for discussion of Firewall-1 
[mailto:[email protected]] On Behalf Of Peter Addy
Sent: 20 June 2011 09:22
To: [email protected]
Subject: Re: [FW-1] Please help!!! " Reason: Smart Center Server aborted 
connection with peer, due to timeout = 300000( mili-sec )( port = 18191 )

Thanks, appreciate the detailed reply.
The firewalls are currently managed by a P-1 but will be managed from a smart 
center, if the nat occurs naturally and back then do we still need to have nat 
rules applied, any idea how the nat rules will read?




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]
=================================================

Reply via email to