Поделиться через

RRAS Ports are not created after enabling VPN on ISA Server 2006

  • Статья

1. Introduction

This post is about an issue that was causing VPN Clients not being able to establish a VPN connection with ISA Server 2006.

2. Symptoms

When testing the VPN Client access in this particular scenario we could see on ISA Server Logging that the system rule that allows VPN Client access was identified but it shows an error saying: Failed Connection Attempt:

Error1

Using the command netstat -nao we verified that there was no process listening on port 1723, which is not correct since svchost.exe should be listening on TCP 1723 when ISA has VPN Enabled. The other non expected behavior was notice in the RRAS Manager that has no PPTP ports available as shown below:

Error2

3. Solution

It turns out that there was a server publishing rule that was using custom protocols on high ports (1500 to 2000) and causing RRAS not being able to grab TCP port 1723. After deleting this rule and restarting the Microsoft Firewall Service the issue was resolved.

 

Author

Saurav Datta

Sr. Support Engineer

Microsoft CSS Security Team

Technical Reviewer

Yuri Diogenes

Sr Security Support Escalation Engineer

Microsoft CSS Forefront Edge Team

Comments

  • Anonymous
    January 01, 2003
    Hi, This is very helpful article to understand TMG as a product and its features. By default categorization of a specific Web site is determined by the Microsoft Reputation Services (MRS) as i find for URL filtering in Microsoft site. I found in description of URL filtering MSAS categorizer is mentioned . I want to know does it mean same thing as MRS ? Thanks Sachin Rana

  • Anonymous
    January 01, 2003
    thank you

  • Anonymous
    July 27, 2010
    I'm having the same issue right now under EBS 2008. But I dont see any web publshiing rule pertaining to 1723.  

  • Anonymous
    September 30, 2010
    Same as Eddie - EBS 2008, all the PPTP ports are gone as of yesterday, and is not listening on TCP 1723.  L2TP and PPPoE ports show up fine though.  It's been running without a hitch since the start of the year.  Any other suggestions?

  • Anonymous
    September 30, 2010
    Eddie, if you're still having this issue, move the internal network adapter to the top of the bindings in the Network Connections advanced window, if it's not already.  Mine was below the external adapter.  No restart of services required, I disabled (enabled L2TP to give it something), re-enabled PPTP via the FF TMG MBE console, and it sprung into life immedtiately - ports returned, listening on TCP 1723, and clients connected immediately. This must be something they missed in the design of EBS, I would have expected this to be one of the fundamental included setup configs.  In any case, setting it manually worked for me.

  • Anonymous
    December 08, 2010
    For anyone's future reference, my last post regarding the network adapter bindings order is still relevant, but this issue recurred again this week after rebooting the server.  I tried everything, changing options within RRAS instead of FF TMG (ISA), disabling and enabling ports and the entire VPN config via both FF TMG and RRAS, changing to DHCP instead of static client IP addressing, and whole lot more.  I even disabled RRAS entirely and had FF TMG recreate the config from scratch - nothing.  I know there's nothing conflicting in the settings on the server as it normally works and nothing's changed, but I checked anyway - nothing in the rules and nothing listening on TCP port 1723.  So I rebooted twice, et voila!  The ports are listed in RRAS, it's listening on 1723, and I can create PPTP connections to the server! I've no idea what causes this, but the settings are all correct, and the only resolution to this bug that I've found is to reboot the server until the ports are listed. Also, this doesn't occur with L2TP or SSTP. Hope that helps if you are pulling your hair out like I was.

  • Anonymous
    July 10, 2011
    This (the original post) resolved the issue for me. Just something that I found that helped me:  I spent a lot of time trying to find exactly which connection was blocking the port.  When it struck me.  I went to monitoring in ISA and set file to filter by destination port equals 1723.  Then confirmed I was looking at the "right" location by trying to connect my VPN (which of course failed, but did show up in the logs).  then I waited, and a few minutes later I saw records of another device trying to connect to the server on the same port.  This indicated to me the rule that I needed to disable to prevent the port being opened by the "wrong" service.    Disabled the offending rule for testing, restarted the Microsoft Firewall Service and viola!  VPN is working.