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
312-578-5262
"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
> (860) 599-3910x2358 North Stonington
> (703) 246-0266 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
================================================================================
