Arkwright All-Knowing Sage ✭✭✭✭
Reactions
Comments
-
Unfortunately the contents of the DROPPED line are not especially useful. It definitely does not tell you what policy it is that causes the traffic to be dropped, despite it being obvious to pretty much anybody that that's exactly the kind of information one would hope to see there. Also, "Policy" could be any of route…
-
Try http:// instead, see if you get a Sonicwall block page.
-
If the issue is what I think it is then unfortunately it will not be fixed on 2600: https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2024-0015
-
It's random though, script kiddies doing bulk login attempts. Just because it doesn't crash immediately does not mean your device is not vulnerable. Disabling SSLVPN service on WAN and leaving it for some time is probably best way to be sure. Issue was resolved in 6.5.4.15:…
-
Try disabling SSLVPN service, does the problem go away?
-
Funnily enough, yours could be the fourth thread with posts in this month from different gen6 users with rebooting firewalls: My guess is this SSLVPN vuln that was patched recently.
-
What is uptime on here? These log messages look like your firewall is rebooting.
-
This is a total aberration from SonicWall, their customers have to pay to get the solution to a problem they created themselves.... Did you upgrade to 6.5.4.15 without support in place? In that case, your users only have you to blame for ending up in this position.
-
If you want the traffic to be encrypted, add it to the VPN policy at both sides [Both sides of the VPN need agree on which subnets are in use, for this to work].
-
Update the firmware.
-
I don't think PortShield works for WAN interfaces but there are some other modes. L2 bridge mode might work, but I suggest you test it to make sure behaves in the way you're expecting. https://www.sonicwall.com/support/knowledge-base/configuring-layer-2-bridge-mode-in-sonicos-enhanced/170505396170557
-
No expert in gaming here but I would think they have SSL MITM countermeasures in place to prevent the use of tools for cheating, so games may not work with DPI-SSL.
-
And we already told them that the possible root cause is due to unlicensed. This is unlikely - it's possible that Sonicwall "accidentally" a bug to encourage you to buy licenses but this would be pretty underhanded behaviour. The more likely explanation is the SSLVPN vulnerability; tWebMain is [I believe] responsible for…
-
The short answer is "no". Why do you need two physical interfaces in the same network? Is this for redundancy?
-
Multiple subnets in VPN policies with different levels of access control is bread-and-butter stuff for SonicOS. I am guessing here, so I think a diagram might help, but did you ask the third party to create a static route so their replies go the right way?