This is all getting overly complex, and the real answer may be to simply re-locate the new smartcenter to a location that allows it to manage the firewalls WITHOUT NAT, and only worry about NAT'ing the GUI client connections to the management server device (if that is necessary).
Nonetheless, the topology tab controls the physical addressing of the cluster and any virtual (clustered) addresses. The GENERAL tab has an IP address that the management server will connect to in order to control the gateways. This DOES NOT have to be the address of the cluster nearest to the management server (some caveats, see below), it can be ANY physical address present on the gateways. In fact, it is NOT the general address as such when we are talking about clusters, but actually the IP address used in the Cluster Members entry over which the management server will connect to the individual member. So, convention suggests that the cluster object GENERAL address is the cluster (Virtual) address of the EXTERNAL interface. The CLUSTER MEMBERS are each defined using an IP address reachable by the management server, and the contents of the TOPOLOGY table is the physically present addressing for each member gateway and the Virtual IP for the cluster shared interface for each physical network. In your case, it is the IP address for the CLUSTER MEMBERS that will be the 20.20.20.x address "seen" by the management server, but this address should NOT appear in the TOPOLOGY tab interface lists. The antispoofing configuration for the real 10.10.10.x addresses on the managed interface will need to include the NAT'd address of the management server (as seen by the firewalls), as well as any other networks that arrive via that interface (and should therefore be a group object containing the management server address, the local interface network object and then any other reachable nets). I recommend that you draw yourself two diagrams. On the first, label every interface subnet around the cluster with it's network and subnet mask, and the physical and virtual addresses assigned to each interface on each firewall. Label the management server with the IP address that it will have when the packets have been NAT'd and arriving at the firewall. On the second, label the interfaces and management server as the management server sees things - real physical IP address of the management server, the NAT'd IP addresses of the two firewall interfaces that you'll be managing the firewalls from, as well as the physical addresses of the firewall interfaces (and their VIPs). These two separate diagrams should help you understand clearly how the traffic will be looking at each side of the NAT boundary and what that means in terms of objects etc. Finally, DO consider relocating the management server logically (or physically) in the network. NAT'd gui client connections are MUCH easier to cope with than NAT'd management connections between SmartCenter and Firewalls. (You can use tunnelled connections over SSH to run the GUI clients for example and NEVER even think about the NAT involved or indeed maintaining GUI client lists on the management server). Best regards, Steve Mob: +44 7766 704871 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: 22 June 2011 12:16 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 ) Stephen, The firewalls themselves are on a 10.10.10.2 and 10.10.10.3 and cluster IP is 10.10.10.1 We cannot target the 10. but our 10.x gets nat'd enroute to a 20.20.20 where the firewalls then see it as a 10.x so i was thinking the main ip and topology needs to be changed on the firewall object from a 10.x to a 20.x and was thinking should i leave the 10.x in place on the object and simply change this to the 20.x or create another dummy 20.x as main ip and topo, and leave the current 10.10.10.1 in the topo but not as main ip, cheers ________________________________ From: Stephen JT Bourike <[email protected]> To: [email protected] Sent: Wed, 22 June, 2011 11:43:40 Subject: Re: [FW-1] Please help!!! " Reason: Smart Center Server aborted connection with peer, due to timeout = 300000( mili-sec )( port = 18191 ) Peter, The cluster topology is ONLY the physical (and VIP) configuration of the cluster members, it has no relationship at all to how it is managed. You should not be changing anything about the cluster The anti-spoofing configuration for the interface that the management traffic comes through may need some changes if your management server is being NAT'd, to ensure that traffic to/from the management server isn't seen as spoofed. 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 17:30 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 ) Also what are your thoughts on the cluster that will be managed by the smart center, what I mean is it best practice that when changing the cluster ip and topo interfaces to the nat ip you would manage this on and still add back in the real and what was the cluster 10.x on the topo and rename the interface name different is to say eth1-s1pc0 or is this not relevant? On Mon, 20 Jun 2011 11:25 BST Stephen JT Bourike wrote: >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] >================================================= 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] ================================================= Scanned by Check Point Total Security Gateway. 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] ================================================= Scanned by Check Point Total Security Gateway. 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] ================================================= 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] =================================================
