Flyboy44
asked on
SBS 2003 VPN Connection Disconnects After 3 Minutes!
We have a Dell Poweredge 2650 with Small Business Server 2003 Premium installed on it behind a Sonicwall Tele2 network security appliance. Routing and Remote access is configured as well as ISA 2000 on the Poweredge. When I connect to the VPN service on SBS 2003 via my Sonicwall, the connection works perfectly for about 3 minutes and then it disconnects. This occurs when using the VPN (remote desktop) and when I just let the connection sit idle. Here is the connection log from the Sonicwall VPN client:
20:50:56.968 Interface added: 10.0.1.102/255.0.0.0 on VPN "WAN Miniport (PPTP)".
20:51:01.296 My Connections\GroupVPN 10.0.1.0 - RECEIVED<<< ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:51:01.296 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_ACK)
20:51:46.828 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:52:01.156 My Connections\GroupVPN 10.0.1.0 - RECEIVED<<< ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:52:01.156 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_ACK)
20:52:46.843 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:53:01.140 My Connections\GroupVPN 10.0.1.0 - RECEIVED<<< ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:53:01.156 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_ACK)
20:53:46.843 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:54:01.156 My Connections\GroupVPN 10.0.1.0 - RECEIVED<<< ISAKMP OAK INFO *(HASH, DEL)
20:54:01.156 My Connections\GroupVPN 10.0.1.0 - Deleting IPSec SA (OUTBOUND SPI = 2E46A72F INBOUND SPI = FDAABBFF)
20:54:01.156 My Connections\GroupVPN 10.0.1.0 - RECEIVED<<< ISAKMP OAK INFO *(HASH, DEL)
20:54:01.156 My Connections\GroupVPN 10.0.1.0 - Deleting IKE SA (IP ADDR=10.0.1.6)
20:54:01.156 MY COOKIE 2d 74 b6 a1 2e 52 94 a
20:54:01.156 HIS COOKIE 4f 2 69 2f 21 44 c8 91
20:54:39.281
20:54:39.281 My Connections\GroupVPN 10.0.1.0 - Initiating IKE Phase 1 (IP ADDR=10.0.1.6)
20:54:39.312 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK AG (SA, KE, NON, ID, VID, VID, VID, VID)
20:55:02.781 Interface lost: 10.255.100.221
20:55:02.781 Interface lost: 10.0.1.102
This is happening on all our remote clients, all running Windows XP SP2. We have tried this from multiple remote locations and it still happens. Server's ISP is Cbeyond. The connection to the internet for the server is setup like this:
Server -- Sonicwall --- Cbeyond Cisco IAD2400 ---- Internet
VPN Connection Sequence is like this:
Client -- Cbeyond VPN --- SBS 2003 VPN ---- Server
From what I have read on this site and others, people have tried altering the MTU values to fix this. We followed the directions of many of the message boards but none of them fixed anything. The event viewer on SBS 2003 doesn't show anything related to the VPN having an error. We are perplexed as to what this could be.
Anyone have any ideas, your help will be greatly appreciated.
20:50:56.968 Interface added: 10.0.1.102/255.0.0.0 on VPN "WAN Miniport (PPTP)".
20:51:01.296 My Connections\GroupVPN 10.0.1.0 - RECEIVED<<< ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:51:01.296 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_ACK)
20:51:46.828 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:52:01.156 My Connections\GroupVPN 10.0.1.0 - RECEIVED<<< ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:52:01.156 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_ACK)
20:52:46.843 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:53:01.140 My Connections\GroupVPN 10.0.1.0 - RECEIVED<<< ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:53:01.156 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_ACK)
20:53:46.843 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:KEEPALIVE_REQUEST)
20:54:01.156 My Connections\GroupVPN 10.0.1.0 - RECEIVED<<< ISAKMP OAK INFO *(HASH, DEL)
20:54:01.156 My Connections\GroupVPN 10.0.1.0 - Deleting IPSec SA (OUTBOUND SPI = 2E46A72F INBOUND SPI = FDAABBFF)
20:54:01.156 My Connections\GroupVPN 10.0.1.0 - RECEIVED<<< ISAKMP OAK INFO *(HASH, DEL)
20:54:01.156 My Connections\GroupVPN 10.0.1.0 - Deleting IKE SA (IP ADDR=10.0.1.6)
20:54:01.156 MY COOKIE 2d 74 b6 a1 2e 52 94 a
20:54:01.156 HIS COOKIE 4f 2 69 2f 21 44 c8 91
20:54:39.281
20:54:39.281 My Connections\GroupVPN 10.0.1.0 - Initiating IKE Phase 1 (IP ADDR=10.0.1.6)
20:54:39.312 My Connections\GroupVPN 10.0.1.0 - SENDING>>>> ISAKMP OAK AG (SA, KE, NON, ID, VID, VID, VID, VID)
20:55:02.781 Interface lost: 10.255.100.221
20:55:02.781 Interface lost: 10.0.1.102
This is happening on all our remote clients, all running Windows XP SP2. We have tried this from multiple remote locations and it still happens. Server's ISP is Cbeyond. The connection to the internet for the server is setup like this:
Server -- Sonicwall --- Cbeyond Cisco IAD2400 ---- Internet
VPN Connection Sequence is like this:
Client -- Cbeyond VPN --- SBS 2003 VPN ---- Server
From what I have read on this site and others, people have tried altering the MTU values to fix this. We followed the directions of many of the message boards but none of them fixed anything. The event viewer on SBS 2003 doesn't show anything related to the VPN having an error. We are perplexed as to what this could be.
Anyone have any ideas, your help will be greatly appreciated.
You say that you are running ISA 2000 still? That would indicate that you didn't upgrade your SBS with SP1? (all 5 base components, as well as upgrading to ISA 2004. See http://sbsurl.com/sp1 for instructions). Not being fully up-to-date can cause numerous networking problems, due to mismatched versions on the client and server.
"This occurs when using the VPN (remote desktop)"
I realize this may be a bit tangental... but why are you using a VPN connection for remote desktop?
To be honest, your entire configuration sounds a bit too complex. As RobWill stated above, you say that you are connecting to the VPN service on the SBS through your SonicWall, but that log indicates that the SonicWall is the VPN endpoint. How many nodes are you licensed for on the SonicWall?
Jeff
TechSoEasy
"This occurs when using the VPN (remote desktop)"
I realize this may be a bit tangental... but why are you using a VPN connection for remote desktop?
To be honest, your entire configuration sounds a bit too complex. As RobWill stated above, you say that you are connecting to the VPN service on the SBS through your SonicWall, but that log indicates that the SonicWall is the VPN endpoint. How many nodes are you licensed for on the SonicWall?
Jeff
TechSoEasy
ASKER
The sonicwall in our application is acting as the public VPN endpoint. The remote user connects to Cbeyond's (our T1 provider) vpn server which establishes a connection between their remote computer and the WAN port on the Sonicwall. From this point the remote user then connects to the SBS Remote VPN Server which authenticates the remote user according to our domain user group policies.
I have checked the Remote Access Policies and the remote connections for any idle timers but none were configured.
I have not upgraded ISA Server 2000 to the 2004 edition, we didn't know that it was available with SP1. I have ordered the CD set from Microsoft.
We are using the remote desktop connection via the VPN to finish configuring the Poweredge 2650 to replace our older domain controller. We are creating a whole new domain and the IT Administrator was doing a lot of the group policy work from home via the VPN.
We are licensed for 10 nodes on the Sonicwall.
We had this VPN setup working perfectly under Server 2003 Enterprise, but when we went to SBS 2003 it has been nothing but dropped connections. I don't know what the difference is.
We are going to install SP1 and try it again. I will keep this thread updated.
Thanks,
Flyboy44
I have checked the Remote Access Policies and the remote connections for any idle timers but none were configured.
I have not upgraded ISA Server 2000 to the 2004 edition, we didn't know that it was available with SP1. I have ordered the CD set from Microsoft.
We are using the remote desktop connection via the VPN to finish configuring the Poweredge 2650 to replace our older domain controller. We are creating a whole new domain and the IT Administrator was doing a lot of the group policy work from home via the VPN.
We are licensed for 10 nodes on the Sonicwall.
We had this VPN setup working perfectly under Server 2003 Enterprise, but when we went to SBS 2003 it has been nothing but dropped connections. I don't know what the difference is.
We are going to install SP1 and try it again. I will keep this thread updated.
Thanks,
Flyboy44
As TechSoEasy suggested why use the VPN and remote desktop when SBS has built-in Remote Web Workplace which has security advantages and should have better performance than your current configuration. I would at least recommend trying it as it would help to determine where the time out issue are. If it still times out you know it it is unrelated to the SBS VPN.
I have never been a fan of running a VPN (SBS) through another VPN tunnel (Sonicwall) though it will work.
I have never been a fan of running a VPN (SBS) through another VPN tunnel (Sonicwall) though it will work.
ASKER
I have tried using the SBS 2003 RWW, the timeout still occurs. It occurs under any connection to the SBS 2003 server. If the VPN to the Sonicwall is the only connection established, it does not time out and will stay logged in for hours. However, when the second connection to the SBS 2003 VPN server is established on top of the Sonicwall VPN, the connection drops after 3 minutes.
If that is the case I would suspect MTU values, however it would not normally be a consistent 3 minutes and it is more common with VPN clients than site to site VPN's. However, if you wish to look at that avenue:
Dropped connections can often be caused by too high an MTU (Maximum Transmission Unit) size, especially if it is a lower than normal performance connection. It is recommended you change this on the connecting/client computer and when possible, it's local router. The easiest way to change the MTU on the client is using the DrTCP tool:
http://www.dslreports.com/drtcp
As for where to set it, if not using automatic, it has to be 1430 or less for a Windows VPN which uses PPTP if using the basic client (1460 for L2TP). There are ways to test for the optimum size of the MTU such as:
http://www.dslreports.com/faq/5793
However, this is not accurate over a VPN due to additional overhead. The best bet is to set it to 1300, and if it improves the situation, gradually increase it.
A couple of related links:
http://www.dslreports.com/faq/7752
http://www.chicagotech.net/vpnissues/vpndorp1.htm
Dropped connections can often be caused by too high an MTU (Maximum Transmission Unit) size, especially if it is a lower than normal performance connection. It is recommended you change this on the connecting/client computer and when possible, it's local router. The easiest way to change the MTU on the client is using the DrTCP tool:
http://www.dslreports.com/drtcp
As for where to set it, if not using automatic, it has to be 1430 or less for a Windows VPN which uses PPTP if using the basic client (1460 for L2TP). There are ways to test for the optimum size of the MTU such as:
http://www.dslreports.com/faq/5793
However, this is not accurate over a VPN due to additional overhead. The best bet is to set it to 1300, and if it improves the situation, gradually increase it.
A couple of related links:
http://www.dslreports.com/faq/7752
http://www.chicagotech.net/vpnissues/vpndorp1.htm
ASKER
I forgot to mention that I have both vpn client connections set to use the "Default Gateway on Remote Network" checked under the advanced button on the TCP/IP section of the Networking tab in the connection properties. I unchecked this on both connections and I did not experience a disconnect, and it's been 15 minutes.
I cannot, however, then connect to the SBS 2003 RWW because I am not on the same gateway as the SBS Server.
Any ideas why it works with the "Default Gateway on Remote Network" unchecked on both connections?
I cannot, however, then connect to the SBS 2003 RWW because I am not on the same gateway as the SBS Server.
Any ideas why it works with the "Default Gateway on Remote Network" unchecked on both connections?
No I am afraid I have no idea why that would be related to the time out.
However, to confirm:
-You make an L2TP/IPSec connection with a VPN client to Cbeyond
-Then the connection from their to your Sonicwall is established with the Sonicwall IPSec site-to-site VPN
-Once connected you start the SBS PPTP VPN connection to the server through the established tunnels
-When that is connected you start an RDP session.
-It's a miracle. I am impressed :-)
However, to confirm:
-You make an L2TP/IPSec connection with a VPN client to Cbeyond
-Then the connection from their to your Sonicwall is established with the Sonicwall IPSec site-to-site VPN
-Once connected you start the SBS PPTP VPN connection to the server through the established tunnels
-When that is connected you start an RDP session.
-It's a miracle. I am impressed :-)
ASKER
RobWill -
That is correct, however I am unable to connect to RDP or the RWW under this condition. I am able to map network shares though. I am going to have to do a little more digging on this problem, but I think it is safe to say that the connection works with no drops if the "Use Default Gateway on Remote Network" box in turned off in the VPN connection properties.
That is correct, however I am unable to connect to RDP or the RWW under this condition. I am able to map network shares though. I am going to have to do a little more digging on this problem, but I think it is safe to say that the connection works with no drops if the "Use Default Gateway on Remote Network" box in turned off in the VPN connection properties.
The default gateway option enables/disables split-tunneling. I can see why if it were enabled on the Cbeyond
connection you might not be able to connect at all but surprised that it would time out.
Are there any duplicate subnets in the path such as 2 sites local, SBS, or in between that use something like 192.168.1.x? They must all be different. Enabling the default gateway in some cases will eliminate the problem for connection to the VPN server but disabling in this case will break the connection.
connection you might not be able to connect at all but surprised that it would time out.
Are there any duplicate subnets in the path such as 2 sites local, SBS, or in between that use something like 192.168.1.x? They must all be different. Enabling the default gateway in some cases will eliminate the problem for connection to the VPN server but disabling in this case will break the connection.
ASKER
There are no 192.168.1.x subnets in the path to the VPN. This is the path from the IAD2400 into our shop:
Sonicwall (10.0.1.x) -- SBS 2003 (10.0.1.x)
IAD2400 (10.0.1.x) -- Linksys 5 port Switch ---<
BackOffice 2000 (10.0.1.x)
The leg with the BackOffice 2000 will be removed completely when the SBS 2003 Server is ready to take over all network operations at the shop. I do have a Hawking WiFi router attached to the 5port switch also, it does have the 192.168.1.x subnet on it, but it shouldn't be affecting the SBS 2003 server. It is only used for guest internet access.
Sonicwall (10.0.1.x) -- SBS 2003 (10.0.1.x)
IAD2400 (10.0.1.x) -- Linksys 5 port Switch ---<
BackOffice 2000 (10.0.1.x)
The leg with the BackOffice 2000 will be removed completely when the SBS 2003 Server is ready to take over all network operations at the shop. I do have a Hawking WiFi router attached to the 5port switch also, it does have the 192.168.1.x subnet on it, but it shouldn't be affecting the SBS 2003 server. It is only used for guest internet access.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
Ok,
We are in the process of installing the SBS 2003 SP1. We have the premium edition so I wanted to order the CD containing the ISA 2004 and SQL 2000 updates but on Microsoft's website it states that no orders will be taken after December 30, 2007. Looks like we should have made the switch to SBS 2003 sooner.
After the SBS 2003 Standard updates are installed we are going to reconfigure the network to use the ip subnet of 172.20.255.x
I will post the outcome here.
Thanks for all your help so far.
Flyboy44
We are in the process of installing the SBS 2003 SP1. We have the premium edition so I wanted to order the CD containing the ISA 2004 and SQL 2000 updates but on Microsoft's website it states that no orders will be taken after December 30, 2007. Looks like we should have made the switch to SBS 2003 sooner.
After the SBS 2003 Standard updates are installed we are going to reconfigure the network to use the ip subnet of 172.20.255.x
I will post the outcome here.
Thanks for all your help so far.
Flyboy44
Please forgive me if my assessment of this situation is wrong... but it really looks to me as though you are taking an Enterprise Level approach to a situation that doesn't need it and actually could hurt it. You say you have a 10-node sonicwall... which means this is a small network!
It looks as though you are migrating from an SBS 2000 (BackOffice 2000) to SBS 2003. What's really strange here, is that if you are upgrading to SBS 2003, how is it that you are using old media that doesn't include SP1?
Just FYI, there is very good documentation for migrating from SBS 2000 to SBS 2003 which you'll find here: http://sbsurl.com/migrate. It's always a good idea with SBS to follow all documented methods to install and configure. For instance, you say that you are creating all these NEW group policies... but are you aware that SBS 2003 has a number of default GPO's already? There shouldn't be a need for doing much with group policies except if you need to restrict things further... but those should only be added as additional GPO's.
Your IP Subnetting seems to be a Class A subnet... so I'm wondering if you are using a wider subnet mask than 255.255.255.0? If so, then you are going to have all sorts of unnecessary traffic that can cause the problems you are seeing. SBS networks should use Class C subnets (ie, 192.168.x.x with a subnet mask of 255.255.255.0). This is because that provides 254 IP addresses which is more than three times the number that is permitted within SBS licensing... so it's plenty. It is recommended to use 192.168.16.x as the IP Subnet for SBS in order to avoid VPN conflicts.
That's true that you missed the order date for getting the upgrade to SQL 2004 as part of SP1. But to be honest, I don't use ISA for any of my clients, I use SonicWall's instead. Since you already have a SonicWall, ISA is pretty redundant and will only cause you a lot more complications than its worth. I'd suggest that you uninstall it.
Overall... if you are working with SBS you need to really leave your "enterprise" mind at the door, and do things the SBS-way. Take a quick read of http://sbsurl.com/itpro to get the highlights of what I'm talking about. If you deploy SBS the way it was designed, it works wonderfully. It's stable, secure, and easy to maintain.
Jeff
TechSoEasy
It looks as though you are migrating from an SBS 2000 (BackOffice 2000) to SBS 2003. What's really strange here, is that if you are upgrading to SBS 2003, how is it that you are using old media that doesn't include SP1?
Just FYI, there is very good documentation for migrating from SBS 2000 to SBS 2003 which you'll find here: http://sbsurl.com/migrate. It's always a good idea with SBS to follow all documented methods to install and configure. For instance, you say that you are creating all these NEW group policies... but are you aware that SBS 2003 has a number of default GPO's already? There shouldn't be a need for doing much with group policies except if you need to restrict things further... but those should only be added as additional GPO's.
Your IP Subnetting seems to be a Class A subnet... so I'm wondering if you are using a wider subnet mask than 255.255.255.0? If so, then you are going to have all sorts of unnecessary traffic that can cause the problems you are seeing. SBS networks should use Class C subnets (ie, 192.168.x.x with a subnet mask of 255.255.255.0). This is because that provides 254 IP addresses which is more than three times the number that is permitted within SBS licensing... so it's plenty. It is recommended to use 192.168.16.x as the IP Subnet for SBS in order to avoid VPN conflicts.
That's true that you missed the order date for getting the upgrade to SQL 2004 as part of SP1. But to be honest, I don't use ISA for any of my clients, I use SonicWall's instead. Since you already have a SonicWall, ISA is pretty redundant and will only cause you a lot more complications than its worth. I'd suggest that you uninstall it.
Overall... if you are working with SBS you need to really leave your "enterprise" mind at the door, and do things the SBS-way. Take a quick read of http://sbsurl.com/itpro to get the highlights of what I'm talking about. If you deploy SBS the way it was designed, it works wonderfully. It's stable, secure, and easy to maintain.
Jeff
TechSoEasy
ASKER
So we completed the update to SBS 2003 SP1 and reconfigured the network to use an external subnet of 10.0.1.x and an internal of 172.20.255.x and we are now happy to say that the VPN connection seems to be working like a champ. We are still using two connections, one to the Cbeyond VPN, and then one to the Poweredge 2650 and there have be no dropped connections as of yet. We can connect to the Remote Web Workplace via the VPN without having the "Use Default Gateway on Remote Network" checked on either connection.
Thanks for all of your help!
Flyboy44
Thanks for all of your help!
Flyboy44
ASKER
Thank you for all of your help with this VPN problem. We really appreciate it.
Thanks Again,
Kevin Levy
The EDM Department Inc.
www.edmdept.com
Thanks Again,
Kevin Levy
The EDM Department Inc.
www.edmdept.com
Great! Glad that it was as simple as completing the install of SP1. I guess my initial thought was right on! :-)
Jeff
TechSoEasy
Jeff
TechSoEasy
Thanks Flyboy44. Glad to hear you were able to resolve.
Cheers !
--Rob
Cheers !
--Rob
Assuming SBS is the VPN server, 2 things to check:
-On the SBS open the Routing and Remote Access console under administrative tools. Go to Remote access policies, in the right window check each policy, especially the first by right clicking on it and choose properties, then "edit profile". Make sure no time out periods are set.
-On the client machine right click on the VPN/virtual adapter (called SBS Conection if the SBS connection manager was used) under control panel/network connections and choose properties. Under the options tab, make sure no idle times are set. A manual connection has no default limit, SBS has a 10 minute idle time disconnect, but can be changed.