Did anyone encounter this oddity with SonicOS 7.0.1-5161-R6164?
Larry
All-Knowing Sage ✭✭✭✭
I installed 7.0.1 5161 over 5151 this past weekend.
Looking in the system log this morning I'm seeing a slew of ID=36, Category=Network, Priority=Notice, Message=TCP packet dropped entries.
Looking at a few of them, they all appear to be from foreign countries that are on my Geo-IP block list. And yet, there have been absolutely NO ID=1198, Category=Security Services, Priority=Alert, Message=Initiator from country blocked: Initiator IP:<ip address> Country Name=<country name> entries since the upgrade.
I don't see any reference to a change in Geo-IP blocking in the Release Notes, and can't find anything with a quick Google search..
Has anyone seen or experienced this behavior?
Best Answer
-
CORRECT ANSWERLarry
All-Knowing Sage ✭✭✭✭
This problem was eventually solved in a rather lengthy remote session with a willingly patient CSR.
The ID=36 messages were a deflection from the real problem. At some point in the past another CSR apparently turned on these notifications, which skewed my view of what was happening.
Apparently the ID=1198 message was no longer visible following the 5161 firmware update. The CSR had me revert the firewall's appearance to Gen 6.5 mode and log in. The messages suddenly appeared in that log. After switching back to the Gen 7 appearance, the messages continued to appear and remained.
He had no explanation for why this problem occurred, but he knew enough that this little "trick" could solve some anomalous behavior.
Problem solved.
0
Answers
Three weeks of missed communication with the CSR assigned to this case - with absolutely NO resolution in sight.
First, because SonicWall's support system cannot read and ingest my email responses to outbound messages.
Second, because October has been full of Jewish holidays (which I observe) when the CSR calls expecting someone in the office - and the office is closed - the case gets waylaid for another few days.
Today, when I tried calling, I had to wait 45 minutes on hold, only to be told the CSR could call back "some time later."
No, I'm calling in, and if YOU are not available, then make someone ELSE available to determine what the problem is. You've obtained the logs, you've seen my explanation, and yet YOU need to remote in?
I'm angry about the sheer waste of time and stupidity of it all.
Why yes - posted about this a couple of months ago:
Access Rule to block MAC-adress — SonicWall Community
Created a rule to block the MAC-address, but that doesn't seem to do anything. I think because the packets are already dropped before any other rules come into action. Anyway - I configured the log to skip the 36-events.