With ISA Server 2006 we have a whole new range of supported authentication and delegation methods. They are very well explained in the excellent planning and architecture document Authentication in ISA Server 2006. Because I’m particular interested in two-factor authentication using forms-based authentication for any published Web server, I’ve played quite a bit in my lab with the concept of one-time password support for Remote Authentication Dial-In User Service (Radius OTP).

One of my primary objectives is to find out what the limitations are when we would require the use of two-factor authentication such as Safeword, Vasco or other hardware tokens. By using two-factor authentication we are hoping to avoid that users have to enter domain credentials on non-trusted, read unmanaged, computers. Another objective is that by no means should there be a special software agent required on the clients or the servers to make it work. Otherwise that would defeat the anywhere access goal. In other words, only the ISA server should be aware of the use of the Radius OTP service. This implies that the Radius OTP service doesn’t need to be capable to authenticate the users against the internal domain but instead that the ISA server should use Kerberos constrained delegation to authenticate the users against the published service.

Note: most Radius OTP services have a component that integrates with Active Directory. However, that doesn’t mean the users are authenticated against the internal domain. That integration is very often done to avoid the complexity of synchronizing the Radius OTP and the Active Directory users. In other words, the Active Directory user names are used and the OTP parameters are just extra attributes of those users.

To be able to test it out in a generic way, that means independent of any real hardware token system, I’ve setted up the following scenario in my lab:

On the LAN there is a Windows 2003 SP1 server running Active Directory, Certificate services, DNS/DHCP/IAS, Exchange 2003 and IIS. The installed IAS service (Radius) is domain integrated, that means that the user database used is Active Directory, and is used for the custom remote access policy for the VPN users.  Of course the ISA server is domain integrated.

On the Perimeter there is a stand-alone Windows 2003 SP1 running IIS and a public DNS server. On this server I added the IAS service to be used as the Radius OTP service. This IAS service is completely independent of the internal domain and uses therefore the local SAM as the user database. I’ve created a couple of local users with exact the same user name as in the internal domain. However, take note that the password used should be different to facilitate the testing.

For a general discussion how to setup and configure an IAS service, check out Tom’s two part article Using ISA Server 2004 RADIUS Authentication in Web Publishing Rules.  

The first problem I have to solve has to do with the fact that the Radius servers defined on ISA are global for the whole box and are therefore not configured per web listener. Because I have to support VPN access with a domain integrated IAS as well as a Web publishing rule with a stand-alone IAS, there should be a way to forward the Radius requests to the proper IAS service. Therefore I installed an IAS Proxy service on ISA itself and configured two Connection Requests Policies to route the incoming Radius requests on the basis of some Radius attributes in those requests.

The challenge here is to find the Radius attributes which are a distinctive characteristic of the VPN and Web Publishing Radius requests. After monitoring the Radius requests for a while, it turns out that only the Radius attributes NAS-Port-Type and Authentication-Type are really useful. For VPN Radius requests the NAS-Port-Type is set to Virtual (VPN) and the Authentication-Type is usual MS-CHAP v2 or EAP. For Web Publishing requests the NAS-Port-Type is *not* set at all (why didn’t the designers set it for example to Web instead of leave it empty?) and the Authentication-Type is set to PAP. Moreover, only the Radius attribute NAS-Port-Type can be used in a Connection Request Policy, not the Radius attribute Authentication-Type. To workaround the lack of consistency in the Radius atribute NAS-Port-Type I implemented the following policies:

• On the domain integrated IAS I configured two Remote Access Policies to ensure that only VPN Radius requests are allowed:

  

• On the stand-alone IAS I configured two Remote Access Policies to ensure that only Web Publishing Radius requests are allowed:

  

• On the IAS Proxy I configured two Connection Request Policies to properly route the Radius requests:

  

The second problem I have to solve is related to the fact that the IAS Proxy service is installed on the ISA Server itself. I made that choice due the limited number of servers I can run in my ISA lab (VPC 2004 SP1). It turns out that it is best to configure all IP addresses assigned to all ISA interfaces as Radius Clients of the local IAS Proxy service, otherwise you will get the following Event log:

The third problem I have to solve has to do with the way the users are providing their user name.  Within the user name there are two elements: the identification of the user account name and the identification of the user account location, also known as the realm.  The realm name can be specified in two ways, either as a prefix (e.g. microsoft\) or as a suffix (e.g. @microsoft.com). By default, the IAS service uses as realm the domain name of which the IAS server is member of, or in case of a workgroup environment, the host name of the computer where IAS is installed on. You can change this default behavior by specifying the IAS-supplied domain name through the following registry setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\PPP\ControlProtocols\BuiltIn\DefaultDomain

To avoid that the users must remember two different realms, one for the Web publishing and one for the VPN, we can make the realms the same with the help of the above registry setting. Another way to achieve the same result is to manipulate the realm name in a Connection Request Profile by rewriting the realm or simply dropping it so that only the user account name is passed on for authentication. In that case the IAS service will use his default realm. In my lab I opted for the latter solution and replaced on both the domain integrated and stand-alone IAS the default Connection Request Policy Use Windows authentication for all users with a custom Connection Request Policy Windows authentication with realm stripping as shown below:

Note: to learn more on how Radius attributes can be manipulated, check out the Internet Authentication Service web site.

Once the above Connection Request and Remote Access Policies were implemented, the Radius stuff was working very smoothly for this specific scenario. Looking now a little bit into the difference between the Radius and Radius OTP authentication validation method on ISA server, I see three main differences so far.

First of all, when you select Radius OTP on the Web Listener than the advanced authentication settings Client Credentials Caching is greyed out.  The reason for this is that by definition the passcode of an OTP system can’t be used a second time. Therefore ISA Server does not revalidate the credentials for each request or after a certain time. Rather, ISA Server issues a cookie to the client that allows continued communication without reauthenticating.

Secondly, the default Radius OTP HTML form doesn’t provide you with the choice between a private or public computer as with the default Radius HTML form, although the Application Settings in the properties of the Web Publishing rule let you choose between Always public and As selected by user (public or private). As you probably know, the choice between a private or public computer determines the value of the HTTP header element X-LogonType sent by ISA server to the published service. With the default Radius OTP HTML form the X-LogonType is always set to “public”.  

Thirdly, I have observed that in the case of Radius OTP the field Passcode in the default HTML form is limited to 16 characters maximum. Looking into the HTML code generated by the default Radius OTP HTML form, you can clearly see that there is a limit on the maximum length of the variables username and passcode:

The obvious question is why have the designers done that? Is there a particular reason for or can that be easily changed without negative effect? Honestly, I don’t see any reason why there should be any limitation imposed except for those defined in the Radius RFC’s.  

As from ISA Server 2006 onwards, the preconfigured HTML logon forms can be used in their default configuration, or can be customized, allowing you to provide a different look for the logon forms for different published Web sites. For more information, check out the document Customizing HTML Forms in ISA Server 2006 on the Microsoft ISA Server web site. However, whether the choice between a public and private computer can be easily added to the default or a custom Radius OTP HTML form, is something we’ll have to investigate further. Nevertheless it seems that changing the maximum length of the variables username and passcode in the Radius OTP HTML form is as simple as changing the corresponding Radius OTP HTML file ‘usr_pcode.htm’.

 
HTH,
Stefaan

In the planning and architecture document Authentication in ISA Server 2006 you’ll find a very good overview of the authentication process used by ISA Server 2006. The three major steps are: challenging the user for his/her credentials, validating those credentials against an authentication provider and delegating the validated credentials to the published servers. One of the delegation options you can use is the Kerberos constrained delegation method, which is described in the technical article Kerberos Protocol Transition and Constrained Delegation.

To implement the Kerberos constrained delegation method, the ISA Server must first be enabled on the domain controller to use Kerberos constrained delegation, constrained to a specific Service Principal Name or SPN in short. How to actually accomplish this isn’t very well described on the Microsoft ISA Server site. Lucky for us Tom has already written a two part article serie about Configuring ISA Firewalls (ISA 2006 RC) to Support User Certificate Authentication using Kerberos Constrained Delegation and documented in there how to configure the ISA Server computer account to be trusted for delegation. Despite this excellent step-by-step instructions, you could still make some ‘creative’ mistakes as I’ve learned from hard experience.

If you look at the Delegation tab of the ISA Server computer account in the active directory, you have three main choices as shown in the figure below:

I can’t stress it enough, resist the temptation to select Trust this computer for delegation to any service (Kerberos only), even in a lab environment because it simply won’t work. The reason is that the choices Trust this computer for delegation to any service (Kerberos only) and Trust this computer for delegation to specified services only *AND* Use Kerberos only implies that Kerberos was used to originally authenticate the user against the ISA Server. That’s clearly not the case because Forms Based or Basic authentication is normally used. Therefore, make sure you select Trust this computer for delegation to specified services only *AND* Use any authentication protocol.

As a consequence you have to add the services to which the ISA Server computer account can present delegated credentials. As suggested in the publishing rule, you can list, add and delete Service Principal Names (SPN’s) with the setspn tool. In my lab the Exchange and IIS services were installed on the active directory controller with the FQDN ‘adc.intranet.splab.net’ and the result of the command setspn -L was as follows:

Apparently not all SPN’s are shown with this command because I couldn’t find any entry for the http service. However, don’t panic and don’t start some setspn configurations. Instead you should use the Add wizard on the Delegation tab of the ISA Server computer account in the active directory. There you should find, after selecting the target computer (’adc’ in my lab environment), the http service.

Another thing to watch out for is the FQDN used in the SPN. In my lab environment I have defined the friendly FQDN ‘mail.intranet.splab.net’ for the OWA and RPC Proxy access. This FQDN is a CNAME of the real computer name ‘adc.intranet.splab.net’. After creating the publishing rule on the ISA Server with the FQDN ‘mail.intranet.splab.net’ in the Public Name and To tab, the proposed SPN on the ISA Server is ‘http/mail.intranet.splab.net’ as shown in the figure below:

Obviously this setting won’t work because we don’t have a match with the SPN ‘http/adc.intranet.splab.net’ used in the Delegation tab of the ISA Server computer account in the active directory. By default the SPN in the Authentication Delegation tab of the publishing rule on the ISA Server seems to use what you have specified in the To tab. Again, don’t panic and don’t start some setspn configurations. Instead simply change this SPN on the ISA Server so it matches the SPN used in the Delegation tab of the ISA Server computer account in the active directory.

Update 31/05/2007: Microsoft released an excellent article Kerberos Constrained Delegation in ISA Server 2006.

HTH,
Stefaan

As already said in many articles, blogs and forum messages, the Microsoft command-line FTP client does *not* support FTP passive mode. Therefore, as mentioned in my blog About the FTP Protocol Support in ISA Server, I use the free Standard Networks command-line FTP client MoveIt Freely to test out FTP passive mode.

Lately, I was contacted by some guys who claimed that by using the FTP commands ‘quote PASV’ or ‘literal PASV’ you could use FTP passive mode with the Microsoft command-line FTP client. As proof they supplied a logfile similar to the following one:

At first sight it looks they are right because we see  in the FTP logging that the FTP server tells the client to contact 192.168.1.10 (the FTP server) on TCP port 1682 (6*256 + 146) for the data connection. Moreover, a subsequent data transfer seems to succeed. However, just before the start of the data transfer we see the line ‘200 PORT command successful’ which indicates that FTP active mode will be used. Taking a NetMon trace reveals the plain truth as shown in the figure below:

In frame #3 we see the FTP client (192.168.1.20) setting up the FTP control connection to the FTP server (192.168.1.10). In frame #14 we see the FTP client sending the PASV command to the server and in frame #15 the server responding correctly to this request. However, in frame #17 the FTP client request FTP active mode with the PORT command, followed by a request for a directory listing in frame #19. At last the actual data transfer starts at frame #21 with a connection request from the FTP server to the client. Clearly this is an FTP active mode data transfer.

As a conclusion we can say that the Microsoft command-line FTP client is capable of requesting FTP passive mode with the FTP commands ‘quote PASV’ or ‘literal PASV’ but does not act upon them. Nevertheless, those commands are useful in a server-to-server FTP transfer as explained in How to perform a server-to-server FTP transfer by using IIS.

HTH,
Stefaan

Thomas Shinder wrote a two part article series about how to redirect OWA users to the correct directories and protocols. That article series was originally written with ISA Server 2004 in mind and can be found at:

• http://www.isaserver.org/tutorials/Redirecting-OWA...1.html
• http://www.isaserver.org/tutorials/Redirecting-OWA...2.html

With ISA Server 2006 the solution to redirect the HTTP requests to SSL (HTTPS) requests is very easily implemented by properly configure the Connections properties of the Web Listener as explained in Tom’s blog Redirecting HTTP Requests to SSL Requests using the 2006 ISA Firewall. One of the solutions to redirect the users to the /Exchange folder was to include a special path mapping translating the root path “/” to the special Exchange path “/Exchange\”. However with ISA Server 2006 this is no longer possible because it generate the Event ID 21177 as mentioned in my previous blog ISA Server 2006 and KB917025 and the following ISA Alert:

One possible solution is to include the root path “/” in the OWA web publishing rule and place the following ‘default.htm’ file in the root directory of the OWA site:

Note: you can download the above OWA_default.htm sample page at http://users.skynet.be/spouseele/OWA_Default_htm.txt. Of course don’t forget to change the URL to what is appropriate in your specific environment.

HTH,
Stefaan

This week I upgraded my ISA lab from ISA Server 2004 SP2 to ISA Server 2006. The inline upgrade went very well  except on the ISA Server box ‘ISA Local’ where some third-party Web Filters were installed. Although I first deinstalled all non-compatible ISA Server 2006 third-party products, the Firewall Service refused to start because of a failure in loading the Link Translation filter as shown below:

Thereafter, a bunch of other events are logged, all linked to Web Proxy filter problems. Disabling the rules who used those third-party Web Filters fixed the problem. Hmm… apparently the deinstall procedure of those third-party Web Filters didn’t clean up the configuration very well!

Because I’m very concerned about IPSec tunnel mode site-to-site VPN connections, due to the need for integration with third-party products, the first thing I checked out was if the problem described in my blog When using an IPSec tunnel mode site-to-site VPN you are noticing frequent ISA 2004 error messages “0xC0040014 FWX_E_FWE_SPOOFING_PACKET_DROPPED” was resolved are not. I was a little bit disappointed that that issue wasn’t fixed with ISA 2006. So,  I contacted Microsoft to find out why. Apparently, because there was a valid workaround for this issue, check out KB917025 for more info, it was not worth the effort to fix the problem in ISA Server 2006. Hopefully the next ISA Server version will have a much better support for IPSec tunnel mode site-to-site VPN connections.

HTH,
Stefaan

When you have to support the Secure FTP protocol (aka FTPS or FTP over SSL/TLS) with ISA Server 2000 you have to take some tough decisions, especially if you have to allow Explicit Security. In that case, the Secure FTP protocol uses the default FTP control connection (TCP port 21). Because the FTP Application Filter can’t and will never understand the Secure FTP protocol, and this is by design, you have to unbind the FTP Application Filter from the FTP protocol in order to support Secure FTP in Explicit Security mode. Of course this breaks the normal FTP support. For more information, check out my FTP article How the FTP protocol Challenges Firewall Security, section ‘5. What about Secure FTP’.  

With ISA Server 2004 and 2006 we can solve that Secure FTP dilemma by applying what is explained in the recent ISA Server Product Team Blog article Why do I need a deny rule to make an allow rule for a custom protocol work correctly?. As with HTTP, the binding of the FTP Application Filter to the FTP protocol is a global setting. Moreover, the default FTP protocol definition only specifies the FTP Control connection (primary connection) because the FTP Application Filter handles the Data connections (secondary connections). In other words, unbinding the FTP Application Filter will only allow the FTP Control connection but not the Data connections. So, in order to solve the Secure FTP dilemma we will have to do some more work.

First of all we have to create a custom protocol definition for the Secure FTP protocol (FTPS) as shown in the figure below:

Some important characteristics of the FTPS protocol definition are:

• The FTPS Control connection (Primary Connections) uses TCP port 21 for the Explicit Security mode and TCP port 990 for the Implicit Security mode.
• The FTPS Data connection (Secondary Connections) should be defined as Outbound because only FTPS passive mode can work with a NAT relationship. It is also recommended that the Port Range is specified as exactly as possible. If you don’t know on which ports the Secure FTP server will listen for the data connection, you can specify all unprivileged ports > 1023 (1024 - 65534).
• With the above protocol definition, only Firewall clients will be able to connect to the Secure FTP server due to the secondary connections. If you have to support SecureNAT clients too, you need to adjust the above protocol definition by moving the FTPS Data connection from the Secondary Connections to the Primary Connections section. However, be aware of the security risk associated with specifying such a large port range in the  Primary Connections section.

Next, to allow the FTPS traffic, you need to create two access rules:

• An access rule that uses the custom FTPS protocol and allows traffic from the source network to the computer objects representing the Secure FTP servers.
• An access rule that uses the predefined FTP protocol and denies traffic from the source network to the computer objects representing the Secure FTP servers.

Finally, the new allow rule must come before your original rule that allows the normal FTP traffic from the same source network in the ordered list of policy rules, and the new deny rule should be placed immediately after the new allow rule as shown in the figure above.

HTH,
Stefaan

When using server publishing in a Route relationship, the server publishing rule works like an access rule to allow access to the published server. Clients send requests directly to the IP address of the server being published, and not to the IP address of the ISA Server client-facing network interface. So, what’s than the difference between an access rule and a server publishing rule in such a scenario?

You can find some useful information in the online help topic Access rules and server publishing rules. Additional, in the ISA Server Product Team Blog you can find an article Celebrity Deathmatch: Access Policy Rules vs. Server Publishing Rules containing a fantastic set of facts. We won’t repeat them here. Instead, we like to comment on two of them (Trivial point #4 and Minor point #12) because we’ve seen a slightly different functional behavior as from what might be understood out of that article.

Let’s first describe the following simple but very common scenario:

To show the different functional behavior between a server publishing rule in a Routed and a NATed scenario, we’ve published with the same rule an internal Telnet server (192.168.22.2) onto the ISA External (192.168.1.10) and Perimeter (192.168.33.1) interface. Take note we’ve configured a Route relationship between the Internal and the Perimeter network and a NAT relationship between the Internal and the External network. If we repeat the same server publishing tests but with an internal SMTP or FTP server, we see the exact same functional behavior.

With a standard Telnet Server server publishing rule we see the following relevant creation objects:

That means that from the Internet we have to access the internal Telnet server with the destination socket 192.168.001.010:0023 and from the Perimeter network with the destination socket 192.168.022.002:0023, both as expected.  

Now, let’s look what happens if we modify the server publishing rule and play with the options Firewall Ports, Published Server Ports and Full Proxy mode. 

[Trivial point #4] A server publishing rule can publish services on a different port than the actual service port.

Let’s first change the Firewall Ports and publish the internal Telnet server on the TCP port 2323. The relevant creation objects are than:

That means that from the Internet we have to access the internal Telnet server with the destination socket 192.168.001.010:2323 as expected. However, from the Perimeter network we have to access the internal Telnet server with the destination socket 192.168.022.002:0023.  

Next, let’s restore the default Firewall Ports setting and change the Published Server Ports setting to TCP port 2323. Of course the internal Telnet server must now listen on TCP port 2323. The relevant creation objects are than:

That means that from the Internet we have to access the internal Telnet server with the destination socket 192.168.001.010:0023 as expected. However, from the Perimeter network we have to access the internal Telnet server with the destination socket 192.168.022.002:2323.  

As a conclusion we can say that with a Route relationship you can *not* do any port redirection. In that aspect, a server publishing rule behaves exactly the same as an access rule. 

[Minor point #12] Server publishing rules can do address translation in both directions, so that ISA hides both the address of the client from the server, and vice versa. (Internally, we refer to server publishing rules operating in this mode as “full proxy”.).

Let’s first enable the Full Proxy mode by selecting Requests appears to come from the ISA Server computer in the To tab of the server publishing rule and apply the changes. Then we setup a Telnet connection from an Internet (192.168.1.100) and a Perimeter (192.168.33.10) host. Finally we check out on the Telnet server with the help of the netstat command from which IP address the telnet connections appears to come from. The result is shown below:

That means that the original IP address of the Internet host (192.168.1.100) has been translated by the ISA server to the primary IP address assigned to the ISA internal interface (192.168.22.1) as expected. However, the original IP address of the Perimeter host (192.168.33.10) is not translated at all.

As a conclusion we can say that with a Route relationship you can *not* do any address translation. In that aspect, a server publishing rule behaves exactly the same as an access rule.  

HTH,
Stefaan

Imagine you have to connect to a Partner Network with an IPSec tunnel mode VPN connection. For performance and/or reliability reasons you do so through a dedicated Internet or leased line connection. For this scenario we can draw the following simplified network diagrams:

The important characteristic of the above scenario is that the traffic destined for the Partner Network will not follow the default gateway routing path which is the Internet connection (RT1 in the above diagrams). At first sight you would expect that you only have to define a persistent static route for the VPN gateway at the Partner Network (the outer IP address) pointing to the router (RT2 in the above diagrams) handling that connection to the Partner Network. However that’s not enough in the case of an IPSec tunnel mode connection. Although the IPSec tunnel mode connection itself will succeed, the traffic destined for the Partner Network (the inner IP addresses) will not reach the Partners VPN gateway (the outer IP address) unless you have also defined a persistent static route pointing to the router (RT2 in the above diagrams) handling the connection to the Partner Network for all the destinations (the inner IP addresses) reachable through the Partners VPN gateway (the outer IP address).

The reason for this is the following. When IPsec was architectured for Windows 2000, it turned out that the IPsec RFC’s were rather vague regarding IPSec tunnel mode. Microsoft worked together with other vendors implementing IPsec tunnel mode and found that half of them were implementing the IPsec tunnel as a routable interface, while the other half was not. The goals of the Microsoft implementation were to interoperate with as many other implementations as possible, to perform as well as possible, and to work in as many scenarios as possible, to name a few. So the decision was made that IPsec tunnel mode should not be implemented as a routable interface. When the architecture was done for Server 2003 this decision was upheld. 

What does this mean? It means that for outbound traffic the IP routing decision is taken before any IPSec processing. To understand it better, I strongly suggest you read the Microsoft Cable Guy article TCP/IP Packet Processing Paths dated June 2005. For the above scenario it means that if no static route is defined for the destinations reachable through the Partners VPN gateway, then Windows will choose the default gateway as next hop.  Next, the IPSec encapsulation will be done and the resulting packet with the Partners VPN gateway IP address as destination will be sent to the MAC address of the default gateway. Obviously not the intended behavior. Therefore, you need to specify those static routes for the destinations reachable through the Partners VPN gateway. Take note that this also means that all ISA server versions running on Windows 2000/2003 will have this same behavior.

In the case of a L2TP/IPSec VPN connection the situation is completely different. Here the L2TP packets are protected with IPSec transport mode. Because this doesn’t add an new IP header or changes the current IP header, the routing decision taken on the L2TP packets are still valid after the IPSec processing. So, no extra persistent static routes are needed for a L2TP/IPSec VPN connection.

HTH,
Stefaan

While investigating the “Quick Mode SA idle timeout” problem mentioned in my previous blog A new IPSec Quick Mode Security Association is negotiated every 5 minutes when you use an IPSec tunnel mode connection on a Windows 2003 SP1 based server, we noticed that every time the ISA 2004 server initiate the negotiation of a new Quick Mode Security Association, the packet that triggered that event was lost. If we replaced the ISA 2004 with a Windows 2003 SP1 server as VPN endpoint, we didn’t saw that behavior.

Microsoft PSS further analysed this problem too. It turned out that in Windows Server 2003 SP1 some changes were made in the way the ipsec.sys driver handles traffic during an IKE negotiation. The bottom line is that the packets will be blocked and queued by the IPSec driver. There will be a special flag set on those packets and if the negotiation is over the packets are re-injected into the IP Stack. The Firewall engine Kernel Mode driver fweng.sys is currently not treating this special flag correctly and therefore drops the packets with error code FWX_E_FWE_SPOOFING_PACKET_DROPPED which is a bit misleading in this stage.

However, the ISA development team does not think this is a major area of concern since the IKE negotiation is not happening that often - at least if we assume that the “Quick Mode SA idle timeout” problem has been fixed - and that packet loss must be expected in a networked environment in anyway. Moreover, in all our repro’s we never had a single instance that a TCP connection was dropped due to this issue. The TCP Retransmission took care of the dropped packets. There will be certainly a performance hit for TCP connections due to the Slow Start Algorithm. However, the ISA development team does not see this as a justification for a fix at this moment.

To mitigate the problem, Microsoft PSS suggest to increase the timeout value for the IPSec Security Association Idle Timer to 3600 seconds. Sounds familiar, isn’t it? For more info, check out the Knowledge Base article KB917025 Error message in ISA Server 2004 when you configure an IPsec tunnel mode site-to-site VPN on an ISA Server 2004-based computer: “0xc0040014 FWX_E_FWE_SPOOFING_PACKET_DROPPED”.

BTW — I wonder if this issue has been fixed in ISA Server 2006 RTM. So, any comment on this is more than welcome.

HTH,
Stefaan

I observed that if an IPSec tunnel mode site-to-site VPN is used between two ISA 2004 servers, or between two Windows 2003 RRAS servers, or between an ISA 2004 server and a Windows 2003 RRAS server, then every 5 minutes the Quick Mode Security Association is deleted (Event ID 542) and a complete new Quick Mode Security Association is renegotiated (Event ID 541), although the Security Association (SA) lifetime is 3600 seconds (default value) and despite there is traffic all the time within the tunnel (i.e. ping -t).

According to How Ipsec Works and the IPSec Frequently Asked Questions the default idle timeout for a Quick Mode SA is 300 seconds. This can be changed with the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec
Value name: SAIdleTime
Data Type: REG_DWORD
Value data: 300 - 3600 (default=300)

Back in Januari 2006, I logged a case with Microsoft PSS to fix that problem. Microsoft PSS confirmed that on a Windows 2003 SP1 based server the Quick Mode SA idle timeout function was indeed broken. In fact, the Quick Mode SA idle timeout function no longer resets the timer if there is actual traffic passing for that Quick Mode SA. In other words, by default every 300 seconds (SAIdleTime value) the timeout function will trigger a drop of the Quick Mode SA regardless if there is traffic or not. When new traffic is seen, a new Quick Mode SA will be negotiated. To workaround the problem Microsoft PSS advised to change the SAIdleTime value to 3600 seconds.

Shortly thereafter, I got a private fix for the Windows 2003 SP1 ipsec.sys driver that solves the problem. I was told at that time that this fix would be released with Windows 2003 SP2. However, I noticed that on August 22, 2006 Microsoft released the Knowledge Base article KB923339 FIX: The client connections are dropped frequently when you use the IPsec tunnel through a NAT device on a Windows Server 2003 Service Pack 1-based server. Because the mentioned hotfix contains an update of the ipsec.sys driver and has the keyword “kbwinserv2003presp2fix”, it sounds worth the effort to find out if this hotfix would solve de “Quick Mode SA idle timeout” problem too. So, I have requested that hotfix, installed and tested it in my lab and can confirm it effectively solve the “Quick Mode SA idle timeout” problem. Because this was a Windows 2003 SP1 issue, I think this fix should apply to all ISA Server versions, though I tested it with ISA 2004 SP2 only.

HTH,
Stefaan