DCJ-TX
asked on
Baffled by Dropped RDP connections over Sonicwall VPN
Baffled by Dropped RDP connections over Sonicwall VPN
I am in desperate need of help with an ongoing network issue and would greatly appreciate anyone who can help.
We have a main office and two branch offices connected via VPN. The main office has a Sonicwall TZ210 connected via DSL on X1 and Bonded T1(3 Mbs) on X2, each branch office has a Sonicwall TZ 180 connected via DSL on the WAN port and T1(1.5Mbs) on OPT port. The VPN policy is bound to the T1’s and Http/s traffic is routed to the DSL’s. It has been configured and working well for about 2 years. Several months ago, RDP connections from the branch offices to the terminal server in our main office began dropping and in recent weeks have become very bad.
Symptoms
1) Every few minutes at irregular intervals clients at remote offices lose their TS connection. When it drops it stays down for seconds to minutes at a time. Some days we will go hours with no drops other days it drops every 3-5 minutes.
2) When the remote TS clients get disconnected, they all get disconnected at the same time.
3) During the disconnect, I cannot ping the TS from the remote offices over the VPN, However I can ping the TS from the local network in the main office.
4) During the disconnects, I can ping other servers at the main office from the remote offices over the vpn.
5) RDP connections to the terminal server from the local network do not get disconnected.
From my desktop (192.168.1.100) in our main office, I can RDP into the file sever in our El Paso office (192.168.4.10), While connected I RDP back into our TS (192.168.1.6). After a few minutes, I see the El Paso file server loose it’s RDP connection to our TS but I never loose my connection to El Paso.
What I have tried.
1) Contacted all ISP and verified connections are working properly. There were some connectivity issues with two of our offices. The ISP’s tell me those have been resolved though I am not 100% convinced.
2) Reduced MTU size on all wan interfaces on all sonicwalls to 1436 from 1500. This is the largest I can send over the vpn before fragmentation.
3) Changed the TCP Connection Inactivity Timeout from 15 minutes to 60 Minutes for all LAN->VPN and VPN->Lan Access rules on all the sonicwalls.
4) Changed “Firewall > Advanced Rule Options - Default UDP Connection Timeout from 30 to 61 Seconds (suggested on another site – no noticeable difference)
5) “Allow Fragmented Packets” is turned on in all the access rules.
6) “Fragment non-VPN outbound packets larger than this Interface's MTU” and “Ignore Don't Fragment (DF) Bit” is On for all WAN and OPT interfaces on all Sonic walls
7) Upgraded the Firmware on the TZ210 to the latest
8) Attempted to Update firmware on TZ180’s but the firmware fails to upload. I’ll be making another post about that issue
9) Ran Symantec and Malware bytes scan on TS (clean)
10) Verify the VPN traffic is going over the T1 and not the DSL
11) Verified all TS clients are connecting via the correct local IP (192.168.1.6)
What I plan to try next.
1) Currently there is a cisco switch between the TZ210 and the TS. I will try connecting the TS directly to the SW TZ210 in case there is some issue with the switch
2) I will attempt to resolve the issue with updating the Firmware on the TZ180’s
3) Make sure my office door stays locked and a can of mace is handy.
4) Wait patiently for the advice of those wiser than me ¿
There are only 4-5 users at each remote office – 9 Total.
TS – win 2003 R2 64Bit SP2, Quad Core Xeon at 2.83 Ghz, 12 GIG of ram. It has all MS updates applied. It is not being over taxed.
TZ180’s Firmware Version: SonicOS Enhanced 4.0.3.4-12e
ROM Version: SonicROM 4.0.1.1
TZ210 Firmware Version: SonicOS Enhanced 5.8.1.5-46o
Safemode Version: SafeMode 5.0.1.13
ROM Version: SonicROM 5.0.2.11
THANKYOU!!!
I am in desperate need of help with an ongoing network issue and would greatly appreciate anyone who can help.
We have a main office and two branch offices connected via VPN. The main office has a Sonicwall TZ210 connected via DSL on X1 and Bonded T1(3 Mbs) on X2, each branch office has a Sonicwall TZ 180 connected via DSL on the WAN port and T1(1.5Mbs) on OPT port. The VPN policy is bound to the T1’s and Http/s traffic is routed to the DSL’s. It has been configured and working well for about 2 years. Several months ago, RDP connections from the branch offices to the terminal server in our main office began dropping and in recent weeks have become very bad.
Symptoms
1) Every few minutes at irregular intervals clients at remote offices lose their TS connection. When it drops it stays down for seconds to minutes at a time. Some days we will go hours with no drops other days it drops every 3-5 minutes.
2) When the remote TS clients get disconnected, they all get disconnected at the same time.
3) During the disconnect, I cannot ping the TS from the remote offices over the VPN, However I can ping the TS from the local network in the main office.
4) During the disconnects, I can ping other servers at the main office from the remote offices over the vpn.
5) RDP connections to the terminal server from the local network do not get disconnected.
From my desktop (192.168.1.100) in our main office, I can RDP into the file sever in our El Paso office (192.168.4.10), While connected I RDP back into our TS (192.168.1.6). After a few minutes, I see the El Paso file server loose it’s RDP connection to our TS but I never loose my connection to El Paso.
What I have tried.
1) Contacted all ISP and verified connections are working properly. There were some connectivity issues with two of our offices. The ISP’s tell me those have been resolved though I am not 100% convinced.
2) Reduced MTU size on all wan interfaces on all sonicwalls to 1436 from 1500. This is the largest I can send over the vpn before fragmentation.
3) Changed the TCP Connection Inactivity Timeout from 15 minutes to 60 Minutes for all LAN->VPN and VPN->Lan Access rules on all the sonicwalls.
4) Changed “Firewall > Advanced Rule Options - Default UDP Connection Timeout from 30 to 61 Seconds (suggested on another site – no noticeable difference)
5) “Allow Fragmented Packets” is turned on in all the access rules.
6) “Fragment non-VPN outbound packets larger than this Interface's MTU” and “Ignore Don't Fragment (DF) Bit” is On for all WAN and OPT interfaces on all Sonic walls
7) Upgraded the Firmware on the TZ210 to the latest
8) Attempted to Update firmware on TZ180’s but the firmware fails to upload. I’ll be making another post about that issue
9) Ran Symantec and Malware bytes scan on TS (clean)
10) Verify the VPN traffic is going over the T1 and not the DSL
11) Verified all TS clients are connecting via the correct local IP (192.168.1.6)
What I plan to try next.
1) Currently there is a cisco switch between the TZ210 and the TS. I will try connecting the TS directly to the SW TZ210 in case there is some issue with the switch
2) I will attempt to resolve the issue with updating the Firmware on the TZ180’s
3) Make sure my office door stays locked and a can of mace is handy.
4) Wait patiently for the advice of those wiser than me ¿
There are only 4-5 users at each remote office – 9 Total.
TS – win 2003 R2 64Bit SP2, Quad Core Xeon at 2.83 Ghz, 12 GIG of ram. It has all MS updates applied. It is not being over taxed.
TZ180’s Firmware Version: SonicOS Enhanced 4.0.3.4-12e
ROM Version: SonicROM 4.0.1.1
TZ210 Firmware Version: SonicOS Enhanced 5.8.1.5-46o
Safemode Version: SafeMode 5.0.1.13
ROM Version: SonicROM 5.0.2.11
THANKYOU!!!
ASKER
Thanks hofpad, but load balancing is not enabled. ALSO, We do not loose the VPN. Just the RDP connection.
I had the same problem with a client. Turned out the Sonicwall was just bad, theirs was about 5 years old. When we replaced it with a newer model it worked. If you can temporarily swap out the firewall I would see if it resolves your issues.
ASKER
We have a 40X10 MBps fiber optic line being installed as I speak and I have a TZ215 arriving tommorow. We'll see which if either resolves the problem.
ASKER
Installed Fiber and still having the issue. I think it may be winsock corruption on the windows 2003 trerminal server.
I stumbled upon this http://support.microsoft.com/kb/811259 (see below)
Some of the 10 entries were missing. I only had the first for. I ran the MS fixit and rebooted. Checked and all 10 entries were there. I had no dropps for about 1 1/2 hours. Then they started up again. I checked again and now there are only 4 entries again.
So i am thinking something is corrupting the winsock - But what?
"Method 2: Use the Msinfo32 program
Note Use this method only if you do not have a Windows XP Setup CD and you do not have Support Tools installed. 1.Click Start, click Run, type Msinfo32, and then click OK.
2.Expand Components, expand Network, and then click Protocol.
3.You will have ten sections under Protocol. The section headings will include the following names if the Winsock2 key is undamaged: ¿MSAFD Tcpip [TCP/IP]
¿MSAFD Tcpip [UDP/IP]
¿RSVP UDP Service Provider
¿RSVP TCP Service Provider
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
If the names are anything different from those in this list, the Winsock2 key is corrupted, or you have a third-party add-on, such as proxy software, installed.
If you have a third-party add-on installed, the name of the add-on will replace the letters "MSAFD" in the list.
If there are more than ten sections in the list, you have third-party additions installed.
If there are fewer than ten sections, there is information missing. "
I stumbled upon this http://support.microsoft.com/kb/811259 (see below)
Some of the 10 entries were missing. I only had the first for. I ran the MS fixit and rebooted. Checked and all 10 entries were there. I had no dropps for about 1 1/2 hours. Then they started up again. I checked again and now there are only 4 entries again.
So i am thinking something is corrupting the winsock - But what?
"Method 2: Use the Msinfo32 program
Note Use this method only if you do not have a Windows XP Setup CD and you do not have Support Tools installed. 1.Click Start, click Run, type Msinfo32, and then click OK.
2.Expand Components, expand Network, and then click Protocol.
3.You will have ten sections under Protocol. The section headings will include the following names if the Winsock2 key is undamaged: ¿MSAFD Tcpip [TCP/IP]
¿MSAFD Tcpip [UDP/IP]
¿RSVP UDP Service Provider
¿RSVP TCP Service Provider
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
¿MSAFD NetBIOS [\Device\NetBT_Tcpip...
If the names are anything different from those in this list, the Winsock2 key is corrupted, or you have a third-party add-on, such as proxy software, installed.
If you have a third-party add-on installed, the name of the add-on will replace the letters "MSAFD" in the list.
If there are more than ten sections in the list, you have third-party additions installed.
If there are fewer than ten sections, there is information missing. "
ASKER
I discovered that while the connection is down, if I repair the "local area connection" on the terminal server. The connection comes back up. So i went looking to see exactly what a " repair does" the first thing it does is flushes the arp cache. So I opened a cammand prompt and any time the connection drops I can run:
netsh interface ip delete arpcache
and the connection will imeadiatly come back up. So I know the issues has something to do with the ARP cache but I have no idea where to go from here. Ideas?
netsh interface ip delete arpcache
and the connection will imeadiatly come back up. So I know the issues has something to do with the ARP cache but I have no idea where to go from here. Ideas?
Before you do the arp-flush the next time, try to look at the arp-table (on the terminal server) and find out, if the default-gateway (should be the SonicWALL) is still correct - or if another network item with "bad behaviour" has "taken over" the default-gateway ip?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
This is what worked.
Just an idea: did you check your WAN "Failover & Loadbalancing" Options? Since you have two WANs @ each location, you probably have enabled Load-Balancing?
If yes, did you read anything in your logs about failing one link over to another?
If yes, change the settings for the probe intervals!
(We realized, that SonicWALL changed the default in their newest firmware from 5/3/3 to 5/6/3 - where 5 is the check-interval in seconds, 6 is the amount of unsuccesful checks before failing over and 3 is the amount of successful checks before failing back to the primary WAN).
Good luck!