In my case, it didn't matter what
was going on. I could leave it as just default (i.e. allow all / deny all
standard) with nothing set up 1 to 1, nothing in the DMZ, and it would still
die. And die, and die, and die... There must be something known
with the firmware because of the reply I got from sonicwall when they gave me
the 6.3.1.2 firmware - they *knew*
this will solve my problems. That leads me to believe there was something
they were aware of and able to address.
The problems seemed to go away with me for
6.2.0.0, though, as I said, I couldn't afford to lose the functionality
of the version 8 VPN client...
I also had set myself to 100 HDX. I
never lost anything like web access or something, and even until this point I'm
the only one who even uses the VPN client so far because the firewall hasn't
been stable enough for me to trust it for my VPN users. So I never
had heavy IKE negotiation or anything. For me, it was an all or nothing situation.
It either worked, or it was totally locked.
On the other hand, an associate who used
to work for me bought one for the company he's at now, at the same time I
got this one for my company, and he's had no issues ever. He's
only using it as a NAT server, though, since he has no DMZ machines, etc...
But he's been on 6.3.1.0 since it first came out and he's never had
a single hiccup from it.
Tech support looked through my diagnostic
report I appended to the support request, and they could find nothing wrong
anywhere - I didn't exceed the number of rules, filters,
nothing. All addressing was as it should be, all the settings were fine.
Just something about 6.3.1.0 especially that really just didn't work.
Time will tell if the newer firmware makes a difference. At least VPN is
working again on it. J
John
-----Original Message-----
From: Jesper Bach
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002
11:53 AM
To: [EMAIL PROTECTED]
Subject: RE: [SonicWALL]- Intro
& question
Here's my 2cents on the
PROVX reboots :
I had 5 PROVX'es running
in diferent setups, but all with VPN's configured and they have been running
rock-steady until i happened to configure too many SA's with Pre-shared key.
None of them were running
antivirus or content filtering. All were running NAT and some, but not much,
DMZ traffic.
Then the PROvx CPU would
start to shut down low-priority tasks (read=the web-interface) under heavy load
(IKE negotiation).
The PROvx'es were running
firmware 6.3.1.0 without any problems, but i have them all set at 100mbit/s
HDX.
Now i have had them
replaced with PRO300's with firmware 6.3.1.0 and had no problems since.
This leads me to beleive
that either the HDX/FDX causes your problems, or something external is causing
your PROVX'es to reboot.
Do you have something
special in your setup diffrent from what i mhas mentioned above ?
-----Original
Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: 19. september 2002 17:50
To: [EMAIL PROTECTED]
Subject: RE: [SonicWALL]- Intro
& question
I
had exactly the same problems with my Pro-VX. Sonicwall ended up sending
me a new Pro-300 to replace it. Then the Pro-300 started having similar
issues. Yesterday they gave me a new firmware to address some of the
issues (6.3.1.2), but since I only upgraded it this morning again I have yet to
see if it works long term.
My only fix with the
Pro-300 going crazy was to revert back to 6.2.0.0. But with so many users
running XP and using VPN, it wasn't a solution because only 6.3.1.0 supported
the new version 8 VPN client that you need if you run XP. I'm crossing my
fingers, but meanwhile have ordered a new Watchguard 2500 to replace the
sonicwall - it's just been too unstable to trust for my business anymore.
Some things with the
Pro-VX that have helped me, and some others - don't leave the ports on the
firewall set to autodetect. Hard code them for your switches'
speed. Mine are all 100MB half duplex. That seemed to help mine
some, and a few others. Also, I'd avoid the 6.3.1.0 firmware and stay at
the 6.2.0.0 until they officially release a successor to 6.3.1.0.
Good luck!
John
-----Original Message-----
From: Colin Irwin
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002
10:36 AM
To: [EMAIL PROTECTED]
Subject: [SonicWALL]- Intro &
question
Hi there,
I'm the Managing Director of a web solutions and
hosting company in the UK.
We have 2 x Sonicwall Pro VX. Until recently we had
only one running on the 6.2.0.0 firmware - the other was boxed up as we had not
yet got round to setting up High Availability.
A few weeks ago we upgraded to the latest firmware
and have been having nightmares ever since. The Pro VX kept restarting itself
or locking completely. Looking around Usenet we saw no messages that suggested
this was a common problem with the new firmware and so we decided our first
option would be to set up the 2 Pro VXs as a High Availability pair to offer
better resiliency.
The results of this were mixed. The HA pair worked
fine, with the Secondary kicking in after 10s and relinquishing control back to
the Primary when it came back online. However, one of our server stacks on the
DMZ became invisible on the net when the secondary firewall was active. I
believe this is because the IP/MAC addresses associated with the firewall were
stuck in caches in switches, hubs and NICs and the servers were looking for
IP/MAC1 and seeing IP/MAC2 (IYSWIM).
At present we have rolled back to the 6.2.0.0
firmware on a single firewall and (touch wood) things are stable again. Before
we set up HA again I would like input as to whether my diagnosis of the problem
is correct and what we should be doing to ensure the failover process works
smoothly in future.
The servers are 2 pairs of load balancing Win2k
Servers that all go through the same hub and then on to another hub on the way
to the DMZ port of the Pro VX.
Cheers,
Colin
---
CONFIDENTIAL
NOTICE
This
communication contains information that is confidential and may also be
privileged.
The information in this message is intended for the addressee
only
unless explicitly stated. If you have received this message in error it
must
be deleted and the sender notified. Please note that any distribution,
copying
or use of this communication or the information in it is strictly
prohibited
unless explicitly stated. Emails sent to or received from Spex
Internet
Limited may be intercepted and read by the system administrator.
Interception
will only occur to ensure compliance policies, procedures or
regulatory
obligations, to prevent or deter crime, or for the purposes of
essential
maintenance or support of the email system.
