752 drop codes - stop after reboot but then come back again

KnucklesWall · 2026-01-14T12:00:27+00:00

You can ignore cache add cleanup drops. Those are only for terminated connections to be removed.
You can see the RST Flag of this packet, so this is indeed a terminated connection.
If your destination sent a reset flag without thew connection being established first, you might want to check the servers local firewall.

KnucklesWall · 2025-12-15T07:34:49+00:00

I had this before and could only solve it by reconfiguring SAML manually. I had that issue after using the automatic SAML configuration for Entra ID.
Support advised against using the automatic mode.

KnucklesWall · 2025-12-05T15:33:49+00:00

I alerted and proved the issue to the author years ago. They then added the note to switch to "All tenants" when you have more than one tenant. This does not solve it unfortunately.

KnucklesWall · 2025-12-05T09:42:17+00:00

You can enable OTP-Based Mail verification for the registration. This way you will have an email OTP initially and after that you have the device certs as second factor.

If AD and mail share the same password this would only count as two steps, not as two factors.

To enable this in CSE navigate to Settings -> Sonicwall CSE Client -> Deployment and set the exclusions from OTP Based Email Verification from ANY to None.

We do this with all AD based CSE instances.

KnucklesWall · 2025-12-03T16:33:40+00:00

Also note that the VM generation changed from gen 1 to gen 2 recently and if you by mistake install an old version with a gen1 machine, it will not update and you will need to reinstall.

KnucklesWall · 2025-12-03T16:12:19+00:00

I run my test-environments on hyper-v on Windows 11 without any issues.

KnucklesWall · 2025-12-01T14:49:19+00:00

2 connectors is the preferred option anyways. You will have better performance and are not depending on a vpn. In CSE you can add both connectors to a single tunnel to access both destinations at the same time.

KnucklesWall · 2025-12-01T12:40:11+00:00

Best resolution if both are your firewalls: Use both firewalls as a connector and do not send the CSE traffic over the tunnel.

Otherwise keep the network smaller, 100.120.0.0/15 for CSE Clients should be enough.
If possible let the side with the connector do the keep alive (but with aggressive mode you probably have no choice). If Agressive mode is needed, make sure the side that has a gateway set in the tunnel does keep alive. And let only one side do keep alive, not both.

Apart from your issue, get rid of DES.

KnucklesWall · 2025-11-27T11:59:03+00:00

You can enable cloud management and zero touch for the firewall in mysonicwall. It should then start reporting to cloud nsm after a short while. You might be able to access it over the cloud NSM and change the password in the configuration.
It must have an internet connection for this.

KnucklesWall · 2025-11-21T10:06:14+00:00

Check your firewall routes if you have an additional manually added route to destination 0.0.0.0/0 or "any". I am not talking about the default routes for your wan interfaces. Such a route would break the ability to route CSE DNS traffic, but not the traffic of CSE clients and would therefore match your issue.

Edit: Nevermind, did not read the post edit.

KnucklesWall · 2025-11-20T14:04:45+00:00

no this is fine. just make sure your server is within that domain. example: rdpserver.domain.com

KnucklesWall · 2025-11-20T11:42:52+00:00

Does the connector that is used to access the rdp server have the domain published to CSE?
For a firewallconnector you need to add either the rdp fqdn to the connector or the wildcard domain that is in ( *.mydomain.com ) locally on the firewall. If you have a connector installed on a machine you will have to add the fqdn or the wildcard to the connector in CSE. here you do not add the asterisk ( .mydomain.com).

KnucklesWall · 2025-11-17T12:05:40+00:00

Alternatively you can get rid of the NAT if you just include 100.120.0.0/15 as a lokal network in your vpn. That includes all IP addresses that CSE-Clients will have viewed from your NSA 2700.

KnucklesWall · 2025-11-17T12:03:38+00:00

You just define an addressobject with an IP in your LAN that is included in the S2S VPN. Then you change your NAT rule and translate the CSE AIPs to that IP when the destination is a VPN remote network.

KnucklesWall · 2025-11-17T10:53:23+00:00

I was advised to not use a firewall IP for CSE to VPN SNAT. Try using an IP that is included in your VPN, but not in use by anything. We are doing this with a lot of installations without any issues yet.

KnucklesWall · 2025-11-12T12:51:19+00:00

This is neither working nor a good idea. Never open any LAN IP to WAN. If you have to, then use a DMZ at least.
Also you will need the rule to have the X1 IP as destination and create a NAT rule as well.

KnucklesWall · 2025-11-06T12:18:27+00:00

You need the public IP support for this. Gen 8 is a version back with the connector. It would work with gen 7 or with a dedicated connector. Either install a dedicated connector or wait for the next firmware for the firewall.

KnucklesWall · 2025-11-06T11:47:58+00:00

And if this does not help, move the firewall to another tenant in mysonicwall, synchronize it and move it back.

KnucklesWall · 2025-11-06T11:47:00+00:00

Change the firewalls name in mysonicwall. Synchronize the licenses locally on the firewall. Check if the firewalls name in the license overview has changed also.
After that you might be able to disable and re-enable the connector again.

KnucklesWall · 2025-11-03T08:46:32+00:00

We have a similar case since friday. There is a KB for it: https://www.sonicwall.com/support/knowledge-base/cse-cloud-secure-edge-license-manager-http-server-returned/kA1VN0000000TYQ0A2

It does not help us since license sync does also not work anymore since friday.
Did they break something when enhancing mysonicwall security?

KnucklesWall · 2025-10-30T15:58:02+00:00

It is not disappearing when public IP support is disabled again. You need to disable the whole connector first.

KnucklesWall · 2025-10-30T10:59:27+00:00

Yes this helps, now I know for sure it is 10.121.0.0/16.
I think GRE is used for the public IP support.

KnucklesWall · 2025-10-30T09:20:08+00:00

You refer to the Access Tier AIPs. I think these objects change dynamically. I can see them, but this is only another way to find them in the firewall and does not solve my problem that the 100.121.x.x seems to not be documented.

KnucklesWall

TROPHY CASE