[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [FW1] Flaky NAT on Nokia's
Hello Gentlemen, I have similar issues. This problem happens every once in a while but all of my NAT's are static and manual. I have two IP 440 Nokias running in HA with CheckPoint v.4.0 Enterprise FW-1. My NATing (manual) is acting very suspicious. The NATing is working fine but then all of a sudden it stops. I have to bounce the primary Nokia box to get it going again. I think that this is only isolated to the primary box. These are the steps I followed to get NAT enabled: Define network object with an interface (the NATed IP address) Make the firewall policy to allow the proper services to get across (e.g., TELNET) Create a NAT rule Make a static route entry for the NATed IP address (on both Nokias) Make a VRRP entry for the NATed IP address (on both Nokias) I have gone over my configuration many, many times before. I only have about 50 regular policy rules, 80 NAT rules, and 5 rulebases. This configuration (slightly different) was originally on NT boxes. The Nokias are far more powerful then the old NT boxes. That is why I think it may be somewhere in the configuration. I am working with my VAR but they do not have a solution yet. Please Advise, Wiktor Mikos Network Engineer"Johan Strom" <[email protected]>@lists.us.checkpoint.com on 02/26/2001 09:37:22 AM Sent by: [email protected] To: "Janz, George" <[email protected]> cc: "Fw1 Mailing List \(E-mail\)" <[email protected]> Subject: Re: [FW1] NAT disappears Hello George. Welcome to my world. I have ticket open at checkpoint for this problem i will keep you informed. If you get a solution on this one please inform me. Regards Johan ----- Original Message ----- From: "Janz, George" <[email protected]> To: <[email protected]> Sent: Monday, February 26, 2001 2:28 PM Subject: [FW1] NAT disappears > > For some time we had a problem with address translation. In all cases, the > problem has been with entities - both hidden and static, that have been in > place for quite some time. This absolutely eliminates routing as a cause. > > We run 19 Firewalls - 4 NT and 15 Nokia 330s. Checkpoint on NT is at 4.1 > SP3. Checkpoint on the Nokias is 4.1 SP2 with flows running on IPSO > 3.3-FCS3. The remotes are loaded from a NT mgmt console also running 4.1 > SP3. > The problem exhibits itself as follows. We have remotes that hide multiple > 10Dot address spaces. For no apparent reason, one of the hidden address > spaces looses its ability to browse the Internet. Examination of traffic on > the outside interface shows that the 10Dots are not being translated. It > also exhibits itself for statically translated entities. For example - a > previously availalbe OWA server is no longetr accessible. > In lots of cases, pushing a policy to the failing remote fixes the problem. > In some cases it does not. When it does not, the process of resusitating > the remote is very painful. We have to unload the Firewall, FWstop, delete > the state tables, FWstart. > We have tried applying HOTfix 3701 but it seemed to make it worse, so we > backed it off. We have tried making the connection table bigger, no luck > here either. > The only relief we get is when we eliminate all translation rules generated > automatically. We have to do all address translation manually and this > seems to stop the problem from occurring. This is an undesirable solution > because it creates alot of extra work in setting up entities. > Things we have tried but have not seemed to help: > In objects.C we changed: > :nat_limit (25000) > nat_hashsize (16384) > to > :nat_limit (50000) > :nat_hashsize (65536) > Note: objects.C remains modified as above. > We also tried increasing the size of the connections table in the table.DEF > file to hashsize 65536 limit 50000. This also did not seem to help. Note: > table.def was reset to 8192 limit 25000. > Table.def has also been modified to keep VPN connection alive during a > reload of a policy. Therefore, 'keep' was added after dynamic. > connections = dynamic keep refresh sync expires TCP_START_TIMEOUT > > The above change was made a year ago on the 4.0 SP3 firewall mgmt cosole and > carried forward to preserve the VPNs during a reload. > > The bottom line here is that the only change that has caused a positive > impact was to make stop using automatically generated NAT rules and to do > them manually. The VAR I use made this suggestion as well as the others > above. We are both at our wits end trying to resolve this. If it proves > out the using manual NAT rules versus autoNAT rules gets around the problem, > I will go in this direction until some time in the future when I'll try > autoNat again. I think the VAR has gone a good job as far as helping me, > however, the problem goes unresolved and has had the unfortunate side effect > to giving a previously almost perfectly performing network a very bad black > eye. > > > George Janz >North Stonington >Fairfax > [email protected] > > > > ============================================================================ ==== > To unsubscribe from this mailing list, please see the instructions at > http://www.checkpoint.com/services/mailing.html > ============================================================================ ==== ================================================================================ To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================================================ ================================================================================ To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================================================
|