Accessing Domain Resources When Connected To External VPN Via Windows 7 VPN Client

Recently one of my users was having trouble printing from remote workstations. In this scenario, the user needed to print some reports from a system that resided on a client’s network. She would start up the Windows 7 VPN client, provide credentials, and once connected to the client’s network through VPN, she would start the Microsoft Terminal Services Client and login to the system she needed to print reports from. During this time, the printers on our network (managed by a domain-wide printserver; mapped to workstations via GPO) would become inaccessible. The printers would “show up” on the remote side (as TS Session Printers) as they should, but they just would not accept print jobs.

After some troubleshooting, I found that this only happened when she was connected to the VPN. Whenever I tried to access the print server through a UNC path (i.e., \\printserver\printer ) a username/password box would appear, asking for her domain credentials — but here’s the kicker: the username field would be pre-filled with the username she used to login to the VPN. After some more digging, I came across this blog post and it immediately solved the problem. This was such a pain in the ass that I’ve decided to recreate the text of the resolution here, just in case that post should disappear for whatever reason:

  1. Locate the .pbk file (VPN session file) for the session you want to fix
    • Windows Vista/7: C:\Users\\AppData\Roaming\Microsoft\Network\Connections\Pbk
    • Windows XP: C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Connections\Pbk
  2. Open the file in notepad and search for the following text: UseRasCredentials=1
  3. Change the “1” to a “0”, save, exit.

This tells the operating system not to rely on the RAS credentials that get cached upon initiating the VPN session. In Windows Vista / 7, this option is enabled by default; it wasn’t in Windows XP. I have yet to see/hear a good explanation for why it was changed.

Sonicwall logs flooded with: destination for 255.255.255. 255 is not allowed by access control

I recently deployed a Sonicwall TZ200 (fw version: SonicOS Enhanced 5.6.0.11-61o) and after setting up SSLVPN access, the logs were being flooded with the following message:

1		03/20/2013 13:13:55.416	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
2		03/20/2013 13:13:51.672	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
3		03/20/2013 13:13:50.896	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
4		03/20/2013 13:13:50.176	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
5		03/20/2013 13:13:46.752	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
6		03/20/2013 13:13:46.016	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
7		03/20/2013 13:13:45.464	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control

I found a few discussion threads pertaining to this issue on the Sonicwall forums and I tried some of the solutions offered but none of them worked. If you have an account on the forums, you can see these discussions here:

https://forum.sonicwall.com/showthread.php?t=25636&highlight=destination+255.255.255.255

https://forum.sonicwall.com/showthread.php?t=24107&highlight=destination+255.255.255.255

https://forum.sonicwall.com/showthread.php?t=27473&highlight=destination+255.255.255.255

Through trial and error, I noticed that the messages stopped appearing in the logs (not immediately after, I might add) after disabling “Communication Between Clients” under SSL VPN -> Client Settings, and adding “WAN RemoteAccess Networks” to the Access List for the SSLVPN Services group (on the VPN Access tab) under Users -> Local Groups. The messages returned upon reversing these changes. I also noticed that whenever I enabled/disabled “Communication Between Clients”, the following error message was logged:

Adding L2TP IP pool Address object Failed.

I’m not sure if they’re related but they appeared to coincide. This doesn’t seem like the best remedy but at the time I wasn’t able to update the firmware on this device, so this was the next best thing. I’ll update this post once when I get a chance to update the firmware.