Arkwright Community Legend ✭✭✭✭✭
Reactions
Comments
-
I am not 100% sure here, but I think you're saying CCTV systems should have internet access but not site-site VPN? If so: Create a CCTV zone. Create a CCTV VLAN. Assign to CCTV Zone. Configure VLANs on switches to suit. Do not add the CCTV VLAN to the site-site VPN polices. Review the rules between the zones LAN, CCTV and…
-
Can you configure your new network on a second WAN interface and have the DC remote hands plug that in for you? Sonicwall does not support alias IPs either at all or in any straightforward way, so this is probably going to be your best approach long-term.
-
Have you confirmed this yourself with a packet capture? Plain-old DNS is unencrypted so easy to troubleshoot with Wireshark,
-
Try swapping the cables to X1 and X2 around. Which way does the problem go?
-
Work your way from the Zone setting, The zone where this happened does not have DPI-SSL enabled, so in theory this is impossible, right? AFAIK if neither the source or destination Zone has "DPI SSL Client" enabled, then it should never be re-encrypted. The customer has sent screenshots from a phone showing the firewall's…
-
"show connection failures" Unfortunately on this system, with a user count in the hundreds, there is exactly one connection failure. This is unbelievable given that at sites with 5 users I might see tens of failures listed.
-
ping the internet, the router and the IP of where you're VPNing to simultaneously. Watch for packet drops. I would usually suggest PingInfoView for this - great for ad-hoc network monitoring from an end-user device. But don't know if it works in Wine on a Mac.
-
Give us a clue - what is "the setting" in question?
-
Is hairpin/loopback NAT what you're after? https://www.sonicwall.com/support/knowledge-base/access-a-server-behind-the-sonicwall-from-internal-networks-using-public-ips-loopback-nat/170505780814635
-
Or it is better to change it? Sounds like it, yes.
-
…at both ends?
-
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:…