I am getting this error when connecting to SSLVPN Netextender from a device on the network. However, I can connect from other devices on the same network.
Any updates on this? I have run into the same issue with a few users, but definitely not all users. It also seems to be specific to the latest version of NetExtender (10.3) since it does not happen if I downgrade those users to use version 10.2.x.
I just ran into this on Netextender version 10.3.0 (21). I resolved it by doing 2 things. Not sure which thing fixed it. I first went into Control Panel, add/remove programs and did a Repair on SonicWall NetExtender. I should have tested it then, but instead I went into Services and Restarted the SonicWall NetExtender service. Then I was able to connect without the error occurring.
We are experiencing this issue on 10.3.0 and 10.3.1, when reverting back to 10.2.x there are no issues. We opened a case with TAC and waiting for a response.
Also tried to repair Sonicwall Netextender, however I did not find any option for this in Control Panel. Restarting Sonicwall NetExtender Service did also not help.
Thought I'd reply in here as I believe I'm experiencing this issue since we've been made to start using NetExtender as MS removed Mobile Connect from the Store at end of Jan!
If by "not setting DNS" you mean "Not setting DNS Search domains correctly" then this is what I've had. Spent a good 1 1/2 days troubleshooting and going over LOTS of stuff on Google!
OS: Windows 11 Business
Connecting with a VPN Profile deployed using the Windows 11 VPN configuration (via InTune & a PowerShell script) access worked fine, I was seeing our 2 expected search domains set via ipconfig and I could connect to internal devices whilst on the VPN without supplying the FQDN.
When testing profile connecting with Netextender 10.3.1 I could only access resources if I used a FQDN or IP.
I noticed in the output of ipconfig /all that the connection specific DNS suffix was being set on the SSLVPN connection however it wasn't being added in the search domain section (we have a couple of domains setup to be issued to users, and this works fine with the other profile).
I also used the packet trace option to at the DNS traffic and was able to see in each request that the expected domain was never actually added, hence the failures.
I did get it to work during testing by fudging it somewhat and setting the adapter to "Obtain address automatically" so I was able to update the DNS tab and put in both search domains there, however that isn't a viable solution for automated deployment!
Eventually I thought I'd give an older version a try, especially as 10.3 seems to be a major overhaul with the ARM support and it worked first time! - I could see the expected entries for search domains in ipconfig output and I was able to connect to internal resources exactly as with the Mobile Connect profile.
Have done a bit more testing of this with my manager now and we've discovered that the 10.3.1 client seems to be setting whichever domain is input first under Client Settings>DNS Search List as the Connection Specific DNS Suffix under Windows 11 and then adds the other entries in the Search List (as per ipconfig output)
We tried adding a dummy domain entry first and then had our 2 valid DNS domains after it and after reconnecting the client the DNS Search list is populated as expected and it seems network connections can be made with just hostname.
Connecting to the server with the 10.2 client sets the first entry as Connection Specific DNS Suffix and then adds all 3 to the Search List.
Answers
Any updates on this? I have run into the same issue with a few users, but definitely not all users. It also seems to be specific to the latest version of NetExtender (10.3) since it does not happen if I downgrade those users to use version 10.2.x.
I have the same issue with 10.3.1 (24).
Some help fixing the error would be much appreciated.
I just ran into this on Netextender version 10.3.0 (21). I resolved it by doing 2 things. Not sure which thing fixed it. I first went into Control Panel, add/remove programs and did a Repair on SonicWall NetExtender. I should have tested it then, but instead I went into Services and Restarted the SonicWall NetExtender service. Then I was able to connect without the error occurring.
We are experiencing this issue on 10.3.0 and 10.3.1, when reverting back to 10.2.x there are no issues. We opened a case with TAC and waiting for a response.
Also tried to repair Sonicwall Netextender, however I did not find any option for this in Control Panel. Restarting Sonicwall NetExtender Service did also not help.
Thought I'd reply in here as I believe I'm experiencing this issue since we've been made to start using NetExtender as MS removed Mobile Connect from the Store at end of Jan!
If by "not setting DNS" you mean "Not setting DNS Search domains correctly" then this is what I've had. Spent a good 1 1/2 days troubleshooting and going over LOTS of stuff on Google!
OS: Windows 11 Business
Connecting with a VPN Profile deployed using the Windows 11 VPN configuration (via InTune & a PowerShell script) access worked fine, I was seeing our 2 expected search domains set via ipconfig and I could connect to internal devices whilst on the VPN without supplying the FQDN.
When testing profile connecting with Netextender 10.3.1 I could only access resources if I used a FQDN or IP.
I noticed in the output of ipconfig /all that the connection specific DNS suffix was being set on the SSLVPN connection however it wasn't being added in the search domain section (we have a couple of domains setup to be issued to users, and this works fine with the other profile).
I also used the packet trace option to at the DNS traffic and was able to see in each request that the expected domain was never actually added, hence the failures.
I did get it to work during testing by fudging it somewhat and setting the adapter to "Obtain address automatically" so I was able to update the DNS tab and put in both search domains there, however that isn't a viable solution for automated deployment!
Eventually I thought I'd give an older version a try, especially as 10.3 seems to be a major overhaul with the ARM support and it worked first time! - I could see the expected entries for search domains in ipconfig output and I was able to connect to internal resources exactly as with the Mobile Connect profile.
Have done a bit more testing of this with my manager now and we've discovered that the 10.3.1 client seems to be setting whichever domain is input first under Client Settings>DNS Search List as the Connection Specific DNS Suffix under Windows 11 and then adds the other entries in the Search List (as per ipconfig output)
We tried adding a dummy domain entry first and then had our 2 valid DNS domains after it and after reconnecting the client the DNS Search list is populated as expected and it seems network connections can be made with just hostname.
Connecting to the server with the 10.2 client sets the first entry as Connection Specific DNS Suffix and then adds all 3 to the Search List.