What
bios version does yours have ? mine's are (techsup dump)
:
Revision: b109_10
$
ROM version
5.0.1.0
and
Revision: c108_8
$
ROM version
6.2.0.0
Here's a complete copy of
page 1 of a techsup dump - try and see if yours is different
:
Status
Serial number
Registration code:
ROM Product Name:
Firewall_035
Product Code:
18
Board ID:
0xf0
2002/06/10
09:11:13.208
SonicWALL has been up: 5
Days, 21 Hours, 20 Minutes, 4 Seconds
Firmware version
6.3.1.0
No debug symbols in
firmware
restartRequired:
False
Revision: b109_10
$
ROM version
5.0.1.0
Previous firmware version:
6.2.0
min firmware for this
hardware: 0.0.0.0
max firmware for this
hardware: 0.0.0.0
vers check err:
0
Crypto level:
domestic
VPN Hardware Accelerator
Detected
Processor= "StrongARM / 233
Mhz"
Model=
PRO-VX
Resource language:
eng
RAM size: 16
M
Flash size: 4
M
Flash type:
AMD
WAN 100 Mbps, Full Duplex,
Auto
LAN 100 Mbps, Full Duplex,
Auto
DmzExists
1
DMZ 0 Mbps, Half Duplex
(Macronix), Auto
/jesper
-----Original
Message-----
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 19. september 2002
19:14
To:
[EMAIL PROTECTED]
Subject: RE: [SonicWALL]- Intro &
question
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.
