Microsoft came back with an update after examining network traces from the client and the server. Seems the initial 'scaling' connection works fine but when a second connection is attempted, it fails with no explanation. The Wireshark trace was inconclusive so a NetMon trace was created and sent to Microsoft for analysis.
The NetMon packet trace confirmed what I already suspected, the client packets were not making it to the server (duh?). Microsoft recommends taking a workstation outside the firewall and testing. This would eliminate the firewall from the potential issues.
Sonicwall came back and recommended we change the VPN connection timeout (TCP & UDP) on the firewall. This of course, had no effect as it is not the VPN connection having the issue. The workstations in Australia can access the rest of the network fine. It's just when they try to make a second connection to the terminal server that things go south.
The idea I'm floating around right now is this may have nothing to do with the Sonicwall after all, it could be related to the gateway device at this location provided by the ISP. It has firewall capabilities and may be causing an issue with the Sonicwall.
I need a user connect to the wireless on the gateway device (thereby eliminating the firewall from the equation) and see if he is able to work correctly. This would seem to point back to the firewall being an issue - unless the wireless side of the gateway doesn't go through the same processing as the LAN side of the gateway, where the Sonicwall is.
Things are continuing to develop - unfortunately the picture isn't any clearer...
(to be continued....)
No comments:
Post a Comment