Peter, When you "fw unloadlocal" on the gateways and they become visible to the management server again, presumably they then also send their logs back to the logserver. If this is the case you can probably see from the logs what is happening to connections from the management server using Tracker.
Likely causes of your issue are either antispoofing (not taking account of the NAT occurring between management server and gateways in the antispoofing group on the interface that the management connection arrives at the gateway on) or more simply the fact that the management server is being NAT'd en-route and once the policy installs, the firewall doesn't recognise the NAT'd management server address as being a valid management address. If you have console access to the gateways (either over physical console or remote shell via SSH) then try doing a tcpdump on the interface closest to the management server for tcp/18191 and see what the traffic looks like as it arrives at the gateway and ensure that your policy permits the address of the management properly. You could extend this to an fw monitor to see what really happens inside the FW module too if things appear to be OK on the wire. Lastly, check that the local gateway isn't inheriting some NAT rules for the management connection that are intended to occur only on some other enforcement point. Sloppy NAT rule configuration in policies controlling miultiple gateways can be a gotcha - ALWAYS make sure you set the "install-on" field for manual NAT rules, and if you MUST use automatic NAT, again make sure that the auto-NAT is ONLY applied to the gateways where that NAT has meaning, not to "ANY". One last comment is that using NAT to connect Provider-1 control connections to a remote gateway is NOT as simple as doing the same thing for a SmartCenter. The traditional NAT cludges that get used to make SmartCenters talk to remote gateways are hard to implement in Provider-1 because the CMA object doesn’t have a topology in quite the same way. Where possible, (by which I mean ALWAYS) place your Provider-1 in your network in such a way as to avoid needing to NAT it at all EVER - (in other words, get a small subnet of real world addresses for your Provider-1 and if needs be publish routes for these on internal WAN links to get the routing to/from your management point - it will save you a world of pain.) Hope this helps. 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 07:27 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 ) To add, the only changes being made here are the management rules, all other rules such as vpn remain the same, this is strange as it appears at first glance the policy installs but times out, and no communication can be made from the manager to the firewalls, sic timeout, but when you unload the policy trust works again, sorry to ramble on but I have to resolve this as its getting rather urgent,thanks 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] =================================================
