Arkwright All-Knowing Sage ✭✭✭✭
Reactions
Comments
-
Firewall cannot do this by itself. The closest it comes is to generate alerts when network probes are failing but by that point it's probably too late in terms of user experience.
-
Losing internet access [however briefly] because some random IP tried to bring up a tunnel is not the expected behaviour. There must be something else going on here, or a bug in that version. We generally don't bother tying down IPsec to known site-site IPs [although that's almost certainly best practise] so I see this…
-
I think you're missing a lack of support for the configuration you're attempting :) I can't see how a /32 mask would work on anything other than a PPP link? Biggest mask SonicOS supports is /31.
-
Change the firewall's HTTPS management port from 443 to something else.
-
Typically all logged in SSLVPN sessions immediately disconnect. End users can reconnect to the SSLVPN, but will nearly immediately get disconnected when they begin to send traffic over the tunnel. Yes, we've had this.
-
Loopback NAT is not "obvious" but once you follow the pattern in that KB article it will work, from internal. If you cannot get the simple inbound NAT working to that IP but you can to others then I suggest you double-check everything. Don't expect ping to a NATed IP to work if you haven't included in the services you're…
-
I'm not able to deploy DPI-SSL to all computers and they are many You need to make sure you are only applying DPI-SSL to the computers you are able to install the certificate on. In the scenario you have described, it is not possible to work around the issue by changing the type of certificate.
-
However in checking a few of those IP's and usernames, it doesn't match what we're seeing right now Ditto. None of the IPs or usernames in that list match a sample of what I found on customer firewalls. I think hoping for an exhaustive list is wishful thinking :(
-
So the inbound NAT would be just the same as the .100. IPs and you should be able to get that working the same way, right? IF you want the public reachable from the inside, you need a loopback NAT policy:
-
Turns out there are multiple threads in this forum and on Reddit about this. There is a message on the support number about this. There is a hotfix that Sonicwall built for this. But there's no sticky thread from Sonicwall in here and we haven't had an email about it? Come on!!!
-
It seems like there has been an update to the tools used by hackers recently, as we're seeing similar events with different customers.
-
I would be surprised if the combination of crypto parameters had any effect on packet loss. Do you see the tunnel renegotiating around the time of the dropped packet[s]?
-
There is a certain amount of non-volatile logging done to the tracelogs which you can only find by going to /diag.html. For example, when a firewall reboots unexpectedly, the normal log starts at "Initializing…" but in the trace logs it might say something like "watchdog reboot". I should think that unexpected failovers…
-
but you'd have to use separate switches. No, he wouldn't. He doesn't need DHCP in this second network, so having two L3 networks in one L2 network will work, even if it's not the "prettiest" solution.
-
It's a bit tedious to do this on the firewall, but you can configure individual log events to go to email. You can probably also send them as SNMP traps. The "right" way to do it is to send everything interesting to syslog and then use your syslog server to act on events as you see fit.