I have connected 3 sites together (using the excellent site-to-site vpn guides posted on this site), and it seems to be working well.
However, every 2-3 days, one of the 3 ISA server's RAS service hangs (and that site is then isolated from the other sites). Thereupon, one can't simply restart the RAS service, you have to reboot the machine (often requiring a hard reset)
(01) Has anyone else come across this hanging RAS service issue? (02) Do I need some service packs? (Are you guys installing all the service packs from MS?) (03) Is it bad practise to use the same ISA2004 machine for site-to-site VPN's and client vpn's?
Our company's productivity is suffering so much due to this issue that I am considering rolling back to win2k/isa2k on all 3 servers rather than the current win2003/isa2004 setup.
Any help/suggestions would be greatly appreciated.
Posts: 12
Joined: 28.Apr.2004
From: Berlin / Germany
Status: offline
I am having exactly the same issue. I have a number of remote sites connected to ISA 2004. The remote sites run standard w2k rras, ISA 2000 and ISA 2004. Partly the sites use DSL lines where the IP address is changing all 24 hours, so that the connections are droped and reconnected.
The problems with the RRAS MMC hanging (and having connections in the "establishing connection" state) do only appear where ISA 2004 is on both ends, as far as I can see. I am somehow of the feeling that it has something to do with the old problem that not both ends should be allowed to establish the connection. Under W2k RRAS and ISA 2000 it was ok to clear the checkbox for "establish connection on demand for this route" (don't know what the correct english version is) under static routes. With ISA 2004 this gets overwritten by ISA, even if the credentials have been left empty on the ISA console. What happens than is that the remote site tries to establish a connection with empty credentials while the local site tries to establish the same connection with credentials. Both ends keep in the "establishing connection" than forever. Different to w2k rras this can not be canceled. The console hangs than and the RRAS service can not be stoped (message is that the service does not answer in a timly manner). The only way out is rebooting the machine. ISA 2004 also writes a retry period of one second into the RRAS configuration. This also might cause problems.
Thanks for your post. At this stage I have the credentials configured on both sides for the appropriate connections, however, I also believe it has to do with the connections dropping, and reconnecting.
At this stage, either side can automatically connect to the other site, and then the reverse connection automatically connects, so I believe the configuration is correct. The problem is that it only works for 2-3 days, when suddenly, one of the 2 sides 'jams' in the 'Connecting' state.
However, if you state that you only have this problem with ISA2004-ISA2004 connections, then I am strongly inclined to rollback all my branch sites to ISA2000.
Is anyone out there using ISA2004 site-to-site VPN's in a production environment? Or are most of you using test/VPC environments?
Posts: 12
Joined: 28.Apr.2004
From: Berlin / Germany
Status: offline
Hi Olaf,
under w2k rras and isa 2000 respectively it was not a good idea to have both ends of a vpn connection configured to initiate the connection. They simply can not initiate a connection and aswer a connection request at the same time. I think there was an article of Thomas Shinder telling this too.
I have not read anything so far that this changed under w2k3. But ISA 2004 sets the RRAS parameters so that both ends at least try to extablish the connection. I doubt that this is correct.
The problem that I have is that both sides need to have the ability to 'somehow' initiate a connection should it drop, because I am hosting exchange servers on either side, and any user could send an e-mail to a user on the other side.
However, I suppose I could implement some kind of workaround, by setting up the main office to occassionally 'ping' each remote site, thereby reinitiating any links should they have dropped (however this is a lame workaround).
Regarding my previous issue, I have noticed that the cause of the RAS crash is a system reboot. I rebooted my ISA machine at the main office, and immediately the RAS service at both my branches hung. After the head office ISA server was running again, the branches were unable to reconnect, and needed to be rebooted as well.
In an experiment, I am running a second ISA server at one of my branches, the difference is that this server is running on Windows 2000 instead of Windows 2003 - perhaps win2k's RAS is more stable.
(hey, based on the total lack of response/opinions from the numerous experts on this board regarding this issue, I am prepared to grasp at any straw) ;-)
quote:Originally posted by Peter Frentin: I am having exactly the same issue. I have a number of remote sites connected to ISA 2004. The remote sites run standard w2k rras, ISA 2000 and ISA 2004. Partly the sites use DSL lines where the IP address is changing all 24 hours, so that the connections are droped and reconnected.
The problems with the RRAS MMC hanging (and having connections in the "establishing connection" state) do only appear where ISA 2004 is on both ends, as far as I can see. I am somehow of the feeling that it has something to do with the old problem that not both ends should be allowed to establish the connection. Under W2k RRAS and ISA 2000 it was ok to clear the checkbox for "establish connection on demand for this route" (don't know what the correct english version is) under static routes. With ISA 2004 this gets overwritten by ISA, even if the credentials have been left empty on the ISA console. What happens than is that the remote site tries to establish a connection with empty credentials while the local site tries to establish the same connection with credentials. Both ends keep in the "establishing connection" than forever. Different to w2k rras this can not be canceled. The console hangs than and the RRAS service can not be stoped (message is that the service does not answer in a timly manner). The only way out is rebooting the machine. ISA 2004 also writes a retry period of one second into the RRAS configuration. This also might cause problems.
Has anyone a solution for this?
Kind Regards, Peter Frentin
Hi Peter,
You have the option of not allowing one site to dial. Its in the Remote Site Wizard. Check that out again and you shouldn't run into the potential race condition.
Thanks for your post. At this stage I have the credentials configured on both sides for the appropriate connections, however, I also believe it has to do with the connections dropping, and reconnecting.
At this stage, either side can automatically connect to the other site, and then the reverse connection automatically connects, so I believe the configuration is correct. The problem is that it only works for 2-3 days, when suddenly, one of the 2 sides 'jams' in the 'Connecting' state.
However, if you state that you only have this problem with ISA2004-ISA2004 connections, then I am strongly inclined to rollback all my branch sites to ISA2000.
Is anyone out there using ISA2004 site-to-site VPN's in a production environment? Or are most of you using test/VPC environments?
Cheers Olaf
Hi Olaf,
I don't have any problems with mine, but I only allow one side to dial and the other side to answer. Only one caller, and only one answerer.
I don't allow it to but the ISA Server (not allowed to dial out) tries to dial the remote site (I entered 0.0.0.0 as the remote site because I had to enter something).
Event ID: 20138 Source RemoteAccess Type Error Description A Demand Dial connection to the remote interface failed to be initated succesfully. Interface Information not set.
This morning I had to restart the server again (RRAS hangs).
switched back to RRAS (W2K) as VPN server behind the Firewall. Hope someone finds a solution for this problem. I will watch this topic and if someone finds a solution I will try it *g*...
Posts: 12
Joined: 28.Apr.2004
From: Berlin / Germany
Status: offline
Hi Tom,
yes there is the option in the remote site wizard to define whether the local site can initiate the connection or not. I always let this cleared for remote sites (only the central ISA should initiate the connections). However, looking at the RRAS console, ISA 2004 always places a tick in the checkbox for connect on demand under the static route. And, as far as I can see, the remote site indeed tries to connect (with hundreds of error message 20183 in the system event log that the credentials are missing). So, I am afraid that this can lead to race conditions, but I am certainly not sure. However, I think it should not produce the 20183 error.
OK, let me check into this and see if that indeed is an issue. Again, I haven't had problems so I'm thinking this is a layer 1 or 2 issue, but I think we really need to confirm whether this is a problem or not.
Posts: 12
Joined: 28.Apr.2004
From: Berlin / Germany
Status: offline
I found out that the Dial-out Hours section of the demand-dial interface configuration of RRAS is not overwriten by ISA. So denying dial-out 24 hours seems to stop the dial-out attempts. The 20138 errors are not logged anymore. Since I configured all remote site ISA 2004 this way I had no crash of the RRAS on these sites anymore. But it is still a bit early to say it realy helped.
However I still have occasionaly crashes of the local ISA which is dialing out to all sites. It always happens if a connection needs to redialed due to short internet outages. And it only happens if a ISA 2004 is on the other end.
I try to reproduce these effects on a lab, but this works fine so far.
Posts: 2
Joined: 28.Sep.2004
From: Hobart, Australia
Status: offline
Has anyone come up with a solution for this issue?
We have the exact same problem but with a slightly different configuration: - Main office with ISA 2004 installed on Windows Server 2003 - Remote office with Windows Server 2003 The remote office is configured to initiate the demand dial connection into the ISA Server. RAS on the ISA Server crashes/hangs whenever the remote connection drops and an attempt is made to reconnect. A hardware reset of the ISA Server is then needed.
I tried configuring the ISA Server RRAS as per Peter's suggestion (configuring the dial-up hours in RRAS), without luck.
Posts: 2
Joined: 28.Sep.2004
From: Hobart, Australia
Status: offline
Hi Tom,
We have ADSL at both ends (through the same ISP). Static IP at the main office. Dynamic IP (and dynamic DNS) at the remote office (hence the dial-in being initiated by the remote office). Both servers are domain controllers of our corporate domain.
I am consistently able to crash/hang the main office ISA server just by disconnecting the VPN connection in RRAS on the remote server!
The release notes for the ISA firewall make it clear that if you manually disconnect the site to site VPN link, then you'll probably have to restart the machine, so that's to be expected.
The only time I've heard of these issues is when one side is using a non-business class link (non-dedicated address). Try using a dedicated address on both sides and see how that works.
I have reconfigured my ISA Servers in the following manner:
Main Office -> Remote Office A Main Office -> Remote Office B Remote Office A -> Remote Office B
(The arrow '->' indicates the site that can establish a remote connection to the other site. ie: Main Office can establish a connection to Remote Office A)
I unchecked the 'Local site can initiate connections...' in the Connection Tab of the VPN properties in the ISA MMC app on the applicable remote sites.
I have stuck to my Win2003/ISA2004 combination at all 3 sites for the moment, and will test this configuration to see whether this addresses the crashing problem.
Will keep you posted
Cheers Olaf
[ September 30, 2004, 11:28 PM: Message edited by: Olaf Wagner ]