Sonicwall SSL VPN creates duplicate DNS records.
My remote users use Sonicwall Mobile Connect to use SSL VPN to connect to the network. This was setup by the previous sysadmin. The problem I'm having is that the IP address given out by this protocol only exists for the length of the session. When they disconnect, the IP goes back in the pool. The protocol doesn't use DHCP or check DNS so I end up with multiple DNS entries with the same IP address. Which in turn leads to errors in PDQ inventory. I've made a ticket with PDQ and I'm told to fix my DNS. I've watched both DNS blogs and I have it set up for DNS scavanging & updating, but again, this protocol doesn't seem to follow those rules. I made a ticket with SonicWall and they assure me that SSL VPN doesn't make DNS records even though I'm staring the A records on my domain controller. Has anybody ever come across this issue before? My PDQ is so close to being an accurate representation of the network but this has been a thorn in my side since the beginning.
Comments
Hello all,
we had the same issue for years now. Duplicates in DNS from the Sonicwall DHCP Server. What a pain.
Today, a colleague and I wrote a Powershell Script which deletes the double (or more) DNS entries from Sonicwall DHCP. We put it on a sheduled task an run it every 5min. We have 2 DNS Servers, so not to much trouble with DNS Replication.
Hopefully someone will find this helpfull:
$dns_prefix = "10.1.1." #Your Sonicwall DHCP IP Subnet
$dns_suffix = 1..100 #Array of/for your Sonicwall DHCP Range
$dns_zone = "your DNS Zone Name"
$dns_suffix |
foreach { $ipAddress = "$dns_prefix$_"; Get-DnsServerResourceRecord -ZoneName $dns_zone -RRType A |
Where-Object {$_.RecordData.IPv4Address -like $ipAddress } |
sort-object timestamp -Descending | Select-Object -Skip 1 |
Remove-DnsServerResourceRecord -ZoneName $dns_zone -Force}
Kind regards,
Simon
Andrew,
I am not a DNS expert (and I've never used SonicWall), but I suspect what is happening is your remote users' computers are initiating their own dynamic DNS updates. That is how your AD DNS is getting updated. So, SonicWall is right that SSL VPN doesn't inherently make DNS records, but Windows does. Try disabling this setting for one of your problem children and see if it fixes the issue as a test. Make sure you do it on the SonicWall virtual NIC and not on their actual physical NIC:
Also, SonicWall may say that they are not using DHCP for address assignment but frankly I'm skeptical. If there is a way to increase the DHCP lease duration that might help mitigate this issue, since you won't have two computers using the same IP within the span of a few minutes.
Here is some more info that might be helpful:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc771255(v=ws.11)?redirectedfrom=MSDN
I suspect what is happening is your remote users' computers are initiating their own dynamic DNS updates.
-I think you're right, that makes sense.
Try disabling this setting for one of your problem children and see if it fixes the issue as a test. Make sure you do it on the SonicWall virtual NIC and not on their actual physical NIC:
-But then wouldn't I not have any DNS records for these computers? And wouldn't that in turn cripple PDQ Inventory's process of scanning the computers, and Deploys process of finding the computer to deploy to?
If there is a way to increase the DHCP lease duration that might help mitigate this issue, since you won't have two computers using the same IP within the span of a few minutes.
-This would absolutely solve the problem, but again, the Address Object in Sonicwall doesn't use DHCP and has no modifiable lease duration because it's set to only exist for the length of the session. This doesn't seem to be something they let you change, unfortunately.
Ah, I missed that these are remote users. I was thinking they were just laptop users occasionally connecting to VPN offsite from their laptops or something. You are correct that would completely break DNS for that computer, since that is the only connection that PDQ ever has to that machine.
Unfortunately I can't think of an obvious solution. In theory something like the PDQ agent could help mitigate this, but it's deprecated and there is no ETA on a replacement.
Are there logs in place for the SonicWall that you can easily access? You could probably have something like a PowerShell script in a scheduled task running every x minutes to clean up DNS objects for old SonicWall connections. It's a hack but it might work.
Hi Andrew,
do you found a fix for this? I've got the same problem...
Stefan,
Try the final post from this forum thread, the one by "FranciscoHernandez": https://community.spiceworks.com/topic/369292-change-dhcp-lease-time-on-ssl-vpn-4000
Try to turn up the DHCP lease duration higher. Make sure you have enough addresses in your pool for this, since you could easily run out if you increase the lease duration.
Hi Luke,
thanks, we don't have a sonic wall but a sophos UTM box.
Sadly, there is no possibility to tune the DHCP settings for VPN.
My scavening on Windows DNS is at 1 hour but still old duplicates.
Maybe a powershell script can help here, I'll search in this direction.
You might be able to script something. I never got a solve for this because the SSL VPN in Sonicwall doesn't use the same DHCP type server as the rest of the networks you can create. I made a ticket with SonicWall and they confirmed that there was no way to modify the lease time. I don't know how Sophos' work, but this has continued to be a thorn in my side. Let just hope they eventually re-release the Agent. **Fingers Crossed**
Thanks Simon your Script help sort the DNS and Inventory issue but not helping with PDQ deploying to VPN client, constantly saying reconnection.
Hei John,
so in our environment deplopyments are working now with VPN DNS of Sonicwall DHCP IP Range.
If it´s the same reconnection error, wether with VPN IP Address or Client DNS Name, I would say it´s a sonicwall issue rather than DNS error ;)
I would start with a packet trace on the sonicwall, export it as libpcap to wireshark to investigate the traffic.
If the DNS problem is gone, you could try to reach the Sonicwall Support for further investigation, because there are heaps of places where something can go wrong like DPI, Client or User Authentication Settings, Firewall Rules and many more. Unfortunatly I´m not a sonicwall expert :(
Kind regards and best of luck,
Simon
Hi Simon,
I should have mentioned that we don't have a sonicwall, it's a Watchguard, the thread helped me. I will contact WatchGuard support to see if they can help.
Cheers
John
Justin,
We had the same issue with Fortigate and ended up migrating our end users from SSL VPN to IPSec VPN. SSL VPN on Fortigate does not allow for a DHCP relay but IPSec VPN does. We simply relayed our IPSec VPN DHCP to a dedicated DHCP server where we set a lease duration that is longer than our DNS scavenging timer and that solved our issue.