Your determination is correct about the RDP problem. The VPN problem is most likely the same as what Dan has been fighting. They'd probably show up together (sometimes) because: 1. The ISA fix for the DNS source port randomization grabs ports randomly during service startup and the RRAS service apparently takes issue when ISA grabs UDP:1723 (don't ask) 2. The RDP problem is a race condition. If the RDP service binds first, ISA "port stealing" comes into play. If not, ISA owns that port and RDP can't start. This is also semi-random. IOW, the dice just don't like you sometimes... :) From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Paul T. Laudenslager Sent: Monday, November 23, 2009 8:30 PM To: isalist@xxxxxxxxxxxxx Subject: [isalist] Re: VPN Connection Hi Jim, You know, you are probably right and I'm off target but this has happened on a few machines to me. It's probably the way I build my ISA servers as I do them all the same. I always have a need to RDP to the IP on the external interface. The majority of the time, I never have a problem connecting. However, on the boxes that I have intermittantly had problems connecting with, I've noticed a few common issues... 1. Whenever the ISA box was rebooted unexpectedly - such as a power outage - I noticed that I was unable to connect via RDP when the box came back up until I restarted the firewall service. After the firewall service was stopped or restarted, I could reconnect via RDP to the external IP just fine. Whenever the problem appeared, I was not able to connect via RDP to the ISA box itself. However, I was always able to remote to a published server behind the firewall. I'm not sure why, but that's the way it worked. I would just open up the services applet on the internal server and then "connect to another computer" back to the firewall and restart the firewall service. Once the firewall service was restarted (or just plain stopped), I was able to RDP to the box just fine. Anyway, to make a long story shorter... 2. Whenever the box had problems, the VPN connections always stopped working as well. In fact, this was usually how I found out there was a problem as customers started ringing my phone off the hook. Going through the log files, I usually found the server was rebooted for one reason or the other... Power outages, hardware issues, or even when Microsoft forcefully rebooted it. This was the common theme everytime it happened. The server would boot back up and everything was published... The only problems noticed were VPN connections and RDP issue. I assume that one was related to the other because they always happened at the same time. Thanks for all the help that you (and others) give here on the list. Your friend in Virginia, Paul Laudenslager paul@xxxxxxxxxxxxxxxx<mailto:paul@xxxxxxxxxxxxxxxx> ________________________________ From: isalist-bounce@xxxxxxxxxxxxx [isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison [Jim@xxxxxxxxxxxx] Sent: Monday, November 23, 2009 9:00 PM To: isalist@xxxxxxxxxxxxx Subject: [isalist] Re: VPN Connection er... How did you assemble the two? Yes, there is a problem with having RDP listening on the external interface if you also have a server publishing listener configured to do the same (race condition), but where does this have any relationship to PPTP VPN failures? Jim ________________________________ From: isalist-bounce@xxxxxxxxxxxxx [isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Paul T. Laudenslager [paul@xxxxxxxxxxxxxxxx] Sent: Monday, November 23, 2009 4:08 PM To: isalist@xxxxxxxxxxxxx Subject: [isalist] Re: VPN Connection This is the old dreaded multiple NICs selected for Remote Desktop into ISA. When our server would be rebooted (like a power outage), we could not longer connect properly with RD and VPN's stopped working as well. Restarting the firewall/routing services seemed to get everything working but doing a start/shutdown/restart would NOT resolve the issue. I believe, from what I've read, if you tell Terminal Services to only respond on the Internal NIC card, this problem goes away. However, I like connecting to the outside IP (from remote). So each time I have a problem, I have to remote in to a server BEHIND the firewall and restart the services on the firewall itself. It's a pain, but doesn't happen often. Only when the server reboots does it appear... ie. Microsoft forces a reboot on the server for updates even when you tell it NOT to... go figure. Having the services only responding to one NIC should resolve your VPN issue... Hopefully... <grin> Your friend, -paul From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Ball, Dan Sent: Friday, November 13, 2009 1:30 PM To: 'isalist@xxxxxxxxxxxxx' Subject: [isalist] Re: VPN Connection RRAS is configured to use the C:\WINDOWS\system32\LogFiles directory, but when I looked in there it was empty. I have since enabled the logging of Authentication Requests (from within the RRAS console), so hopefully this will record something next time around. Sorry I don't have much info to work with... I've set the server to reboot itself tonight, so will do some testing this weekend on it (had busy nights this week). From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison Sent: Friday, November 13, 2009 11:23 AM To: isalist@xxxxxxxxxxxxx Subject: [isalist] Re: VPN Connection What about the RRAS logs? Normally, they're located in %windir%\tracing... Jim ________________________________ From: isalist-bounce@xxxxxxxxxxxxx [isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Ball, Dan [DBall@xxxxxxxxxxx] Sent: Wednesday, November 11, 2009 6:36 AM To: 'isalist@xxxxxxxxxxxxx' Subject: [isalist] Re: VPN Connection Not much there either... In the logs I see the server reboot, RRAS service starts, it gets an IP address to use, but I don't see any other messages. Note: The security log doesn't go back far enough, so I'll have to wait until it happens again see if there is anything in that log. From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison Sent: Tuesday, November 10, 2009 4:13 PM To: isalist@xxxxxxxxxxxxx Subject: [isalist] Re: VPN Connection WSACONNREFUSED indicates that the RRAS service is not accepting new connections. What do you find from Routing & Remote Access in the event logs? ________________________________ From: Ball, Dan <DBall@xxxxxxxxxxx> Sent: Monday, November 09, 2009 10:44 To: 'isalist@xxxxxxxxxxxxx' <isalist@xxxxxxxxxxxxx> Subject: [isalist] Re: VPN Connection Well, the ISA traffic monitor shows that the "[System] Allow VPN client traffic to ISA Server" rule generates a "0x8007274d WSAECONNREFUSED" error, but that is about all I could find. Since I'm not exactly sure what time the problems start (we don't use VPN every day) I don't know about the event log. I'll have to try rebooting it tonight and see if it quits working upon reboot. From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison Sent: Monday, November 09, 2009 11:02 AM To: isalist@xxxxxxxxxxxxx Subject: [isalist] Re: VPN Connection Dan, It should be "manual", because the firewall service manages its state. When you say "not going through" - what exactly is happening? What do you see in the RRAS, ISA or event logs at the time the problems start? Jim ________________________________ From: isalist-bounce@xxxxxxxxxxxxx [isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Ball, Dan [DBall@xxxxxxxxxxx] Sent: Monday, November 09, 2009 4:36 AM To: 'isalist@xxxxxxxxxxxxx' Subject: [isalist] VPN Connection A few times over the last couple of months I've had problems with the VPN connections not going through our ISA2006 server. Each time, the problem appears to be in the Routing and Remote Access part of the server. A restart of the RRAS service seems to fix it, but rebooting the entire server does not. I noticed the service is set to Manual startup, is this correct or is it supposed to be set to Automatic? -------------------------------------------------- Dan Ball Network and Systems Technician Marquette Area Public Schools 1103 West College Avenue Marquette, MI 49855 E-Mail: dball@xxxxxxxxxxx<UrlBlockedError.aspx> Phone: (906)225-5779 Fax: (906)225-5377 -------------------------------------------------- ________________________________ This email is confidential and should only be read by the intended recipient. ________________________________ This email is confidential and should only be read by the intended recipient.