BWC Cybersecurity Overlord ✭✭✭
Reactions
Comments
-
7.0.1-5161 is available on MSW and it comes with lengthy release notes addressing a bunch of issues. —Michael@BWC
-
@dpdave some more thoughts what you could try: does the show interface x0 command showing the correct ip address? are you connecting from the 192.168.1.x subnet? did you tried changing the https-port to something different in case some NAT rule is twisting the request? Otherwise I believe the support should address this.…
-
@DPDAVE please check the following while on CLI show administration check what the parameter https-port shows, if it's not 443 than you have to add the port to your request show interface X0 check if management https is set, if not just set it Commit the changes if you had to do any and you should be golden. Word of…
-
@Russell certs are not part of the configuration export file, but if you used the cert which came old TZ 370 you should be good because it's the same cert for all appliances globally, which is my main reason not to use it. —Michael@BWC
-
@ABB_oceansls if it's mandatory that your Radius Servers can see the Clients IP address, you might look into the SMA 500v as alternative to the built-in SSL VPN functionality. It comes with Wireguard as well, which is a big plus. The SMA gives you the option "Use Client IP For Radius Server Logging" which populates the…
-
🤣 that was a good one, I assume the Support Agent meant well, but reality differs a bit (to a lot), at least in my opinion as a frequent flyer. —Michael@BWC
-
@abb_oceansls I totally support this, because without the originating IP the authentication server (radius) isn't able to do additional checks like Geo-Velocity, granular fail2ban etc. But I wouldn't hold my breath that will ever see the day of light. —Michael@BWC
-
Does your FQDN object holds any IP addresses, if not it does not get populated and is useless for the Access Rule. If you're using wildcard objects e.g. *.domain.com the Firewall needs to see the DNS traffic to catch the response. This does not work if you using something like DoH etc. Another possible reason could be if…
-
Did you added X1:V201 as your only Interface to Network → System → Failover & LB at the tab Groups? Otherwise it will not be used as default gateway. X1 should be removed if it's still selected. —Michael@BWC
-
@Dan973 I assume you're a registered SecureFirst Partner? Did you contacted your Partner Account Manager? If you're not a Partner (according to your profile) you might use Public Access over here? Otherwise www.mysonicwall.com if you're talking about the licensing portal. —Michael@BWC
-
@magicmarcnyc your FYI covers the issue, conflicting subnets will not work, change the address space of your LAN and you'll be good to go. —Michael@BWC
-
Do you initiate the SSL-VPN connection to your Firewall and try to access the internet because of your Tunnel All settings, or do you initiage the SSL-VPN session when behind the Firewall on the LAN? —Michael@BWC
-
@YevheniiK what kind of VPN connections we're talking about? Is it a client initiated session (like a SSL-VPN) then DPI-SSL might affect it, but if we're talking about IPsec or Wireguard I cannot see a context. —Michael@BWC
-
@MustafaA I don't get why Mobile Connect on Windows is coming up over and over again, despite the fact it's end of support for nearly two years? What are the security implications of that? Wouldn't it be the time for a proper solution considering the uprise of Windows on ARM etc? —Michael@BWC
-
@emilward if you change the zone assignment of an Object the Access Rules where it got used will not be altered, you have to change them by yourself. Zone assignments are nothing to worry about regarding to NAT Rules on the other hand. —Michael@BWC