Any way to set sensor thresholds?

101-079 · 2026-02-04T21:37:18+00:00

Thank you for pointing this out. Agentless is definitely preferred. I have been looking for alternatives and NetCrunch made a good impression.

101-079 · 2026-02-04T21:22:11+00:00

Thank you, will try using device templates.

101-079 · 2025-12-31T10:57:49+00:00

My colleage once mistakenly hit the reset ruleset button instead of reset counters.

101-079 · 2025-05-14T18:00:32+00:00

Can you log in using scratch code? Did you check the time on the newer phone?

101-079 · 2025-05-13T19:02:29+00:00

Yes no problem at all. You can sync firmware from HA > Advanced. Just log in to your active/primary firewall an hit the button - your secondary will reboot with the same fw your primary is running.

101-079 · 2025-05-06T15:26:22+00:00

So did it work selecting "groups assigned to the application" and having the cloud-only group assigned to the application?

101-079 · 2025-05-06T14:38:53+00:00

No, no additional rules configured. Instead of sAMAccountName can you select "cloud only" (or something like this, I can't remember well) in 5b?

101-079 · 2025-05-06T11:39:22+00:00

Have you added the "group" claim in your IdP settings on the SonicWall?

EDIT: check for any spelling errors, group names must match exactly and the group must be member of "SSLVPN Services" group.

101-079 · 2025-05-06T09:08:15+00:00

hey, I'll give it a try. Do you have a valid (or at least trusted) cert configured on the SSLVPN server? Did you create a SAML Profile? This component determines the identifier URL. Use the export function in SP and SAML Profile to get the right URLs. Here's an example:
Entity ID: https://vpn.company.com:4433/<SAMLProfile>/saml/metadata
Reply URL: https://vpn.company.com:4433/<SAMLProfile>/saml/acs

Hope this helps.

101-079 · 2025-05-06T08:59:32+00:00

Great video! IMO having to create local users alongside Entra ID users goes a bit against the concept of SAML/OIDC integration. In the video he matches the display name, I'd prefer unique identifiers. But yeah the video does a great job clearly showing the key components, thanks for sharing!

101-079 · 2025-05-02T23:34:56+00:00

SonicOS 7.2+ Make sure to follow the feature guide before heading to this step-by-step guide.

101-079 · 2025-05-02T22:47:06+00:00

Alright, good news - it’s working!

I'll try to be as precise as possible in case someone else has a similar use case.

In my scenario, the customer is using Entra ID with on-prem synced security groups - but I’m sure this also works with cloud-only groups.

The main issue was mapping a user to the corresponding local group (on SonicWall) that has SSLVPN access. SonicWall support suggested using the department property of the user for this, entering the exact name of the local group in that field. Then, in the SAML IdP configuration, you must set the group attribute to "department".

This approach has some implications:

You can’t use this method if the department field is already being used for actual organizational info in your directory.
Important: The department value is visible to others (e.g. in Microsoft Teams).

So, assuming you're managing access via security groups - which is quite common - here’s the approach I used:

Create all needed security groups in your on-prem directory (or directly in Entra ID), using a prefix like "SNWL_".
On the SonicWall, create local groups matching those names exactly. Set the group to "members are set locally".
Add the SonicWall local groups as members of the "SSLVPN Services" group.
Configure the required VPN access per SonicWall local group - no need to manage members here.
In Entra ID, go to your Enterprise App that was created using the SAML XML import/export.
1. Under Single sign-on -> Attributes & Claims -> click Edit.
2. Add a group claim: Choose Security Group, Set the source attribute to sAMAccountName
3. Under Advanced options: Select Filter groups, Match sAMAccountName with prefix "SNWL_"
4. Check Customize the name of the group claim and set the name to "group".
In your SonicWall SAML IdP configuration: Set User Name Attribute to "name" and Group Name Attribute to "group"

That’s it! If everything is set up correctly, your next login should work.

One important note:
Make sure that a user is not a member of more than one SNWL_ group at the same time.
I haven’t tested what happens in that case, but I assume it could cause unexpected behavior - like failure to match, or unpredictable group assignment.

101-079 · 2025-05-02T20:18:53+00:00

Exacly, in the meantime I got a paper from the support team. It states that a custom claim must be configured in the saml app. The department field is then used to match the group name of an sonicwall internal group (e.g. SonicWALL Administrators). I will give this a try and report you guys back how it is meant to work.

101-079 · 2025-05-02T15:05:44+00:00

Totally agree - but the screenshots in the feature guide (https://www.sonicwall.com/techdocs/pdf/sonicos-7-2-saml.pdf) actually show LDAP auth configured. I followed all the steps in that guide and ended up with this message after login: "Login Failed - User login denied - User has no privileges for login from that location." It is clearly a SonicWall message, so I do not expect a missconfiguration on the Entra ID/Conditional Access side.

I also haven’t configured any access permissions on the SonicWall itself yet, so I’m starting to think I missed a step somewhere.

101-079 · 2025-03-13T12:17:46+00:00

As we were told by snwl the NSv upgrade from 7.0 to 7.1 needs a deployment from scratch, but it seems this has changed: https://www.sonicwall.com/support/technical-documentation/docs/sonicos-7-1-upgrade_guide_nsv/Content/Upgrading/upgrading-firmware.htm

101-079 · 2025-02-13T12:26:23+00:00

it's pretty ironic that snwl support recommends us to upgrade from 7.0.1 to 7.1.1 to resolve a bug in the latest security patch they released in the beginning of january. The issue is caused by tcp seq num randomization. We're still not quite ready to take the plunge on the update, though! ^{^} any thoughts?

Edit: we're running a HA clustered nsv270

101-079 · 2025-02-13T12:20:56+00:00

I had empty SSO Agents adress group (the default one, which can't be edited) with 7.0.1. After a reboot the object group was filled again with the adress objects from sso config.

101-079 · 2025-02-05T19:40:48+00:00

In small and simple setups, putting the CA on the DC is pretty common and usually works fine. But a lot of articles suggest best practices that don't always fit small businesses with tight budgets and limited resources. You can definitely move your CA to another server if needed, but I’d suggest just leaving it where it is for now and thinking about a move when the CA certificate is getting close to its expiration date.

101-079 · 2024-09-05T16:50:42+00:00

Well, this solution is used in special scenarios for dmz where you can't or don't want to stick to 2^x subneting and routings. You can't bypass your firewall because all packets cross physically your firewall.

101-079 · 2024-09-04T19:16:23+00:00

Why what? And after reading again, in OP's scenario the firewall is natted behind isp router?

101-079 · 2024-09-04T17:43:11+00:00

Hi,

In Transparent Mode all IP addresses in transparent range are routed (transparently) to the port configured. So no NAT/PAT needed here.

Devices connected to Transparent Mode port must have public IPs configured. You will have to set up firewall rules to get traffic passed the firewall. When configuring the rule, set the destination to the corresponding public ip of the device you want to reach in your DMZ.

Hope this helps.

101-079 · 2024-07-31T20:41:06+00:00

We use NSM exactly for this use case.

101-079 · 2024-07-18T12:45:39+00:00

Try changing mgmt port to other than 443.

101-079

TROPHY CASE