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.
