[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [FW1] NAT disappears
I, too, have a ticket open pertaining to this. However, it happens in my
environment and I've NEVER implemented auto. Nat rules so that's not my
problem. Has checkpoint asked you to try to capture the problem by doing an
fw modinfo yet? Here's what they suggested when we started having this
problem. Run:
fw monitor -m iIoO -e "accept;" -o fwmonitor.out
This snoops all interfaces and collects data for checkpoint tech support.
It seems with mine that a policy repush always fixes the problem.
Kevin
-----Original Message-----
From: Johan Strom [mailto:[email protected]]
Sent: Monday, February 26, 2001 9:37 AM
To: Janz, George
Cc: Fw1 Mailing List (E-mail)
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
============================================================================
====
Attachment:
Kevin Martin (E-mail).vcf
Description: Binary data
