Troubleshooting VPN over IPsec

Troubleshooting VPN over IPsec

Microsoft Internet Security and Acceleration Server 2006

This document describes solutions for common issues that may arise when configuring virtual private network (VPN) site-to-site links over an Internet Protocol security (IPsec) tunnel. Microsoft® Internet Security and Acceleration (ISA) Server allows you to configure a VPN site-to-site link between two networks using Point-to-Point Tunneling Protocol (PPTP), Layer Two Tunneling Protocol (L2TP) over IPsec, or IPsec tunneling. The primary reason for using IPsec tunnel mode is interoperability with other routers, gateways, or end systems that do not support L2TP over IPsec or PPTP VPN tunneling.

This document also provides an overview of troubleshooting tools that you can use to investigate VPN IPsec issues.

Troubleshooting tools

The following sections discuss troubleshooting tools.

ISA Server Best Practices Analyzer

The Microsoft ISA Server Best Practices Analyzer Tool scans the configuration settings of the local ISA Server computer and reports issues that do not conform to recommended best practices. It can run on any computer with Microsoft .NET Framework 1.1 installed and one of the following versions of ISA Server:

ISA Server 2006 Standard Edition
ISA Server 2006 Enterprise Edition
ISA Server 2004 Standard Edition
ISA Server 2004 Enterprise Edition

Install and run the ISA Server Best Practices Analyzer, as follows:

Download the ISA Server Best Practices Analyzer from the Microsoft Download Center. Installation files are copied to the %SystemDrive%\Program Files\IsaBPA folder.
Run the tool from the Start menu. To do this, click Start, point to All Programs, point to Microsoft ISA Server, point to ISA Tools, and then click ISA Server Best Practices Analyzer. Click Start a scan to run the tool.
Review the results, and fix any issues. When you run the ISA Server Best Practices Analyzer, each error or warning has an associated Help topic, with instructions about how to fix the issue.

For ISA Server Enterprise Edition, install the ISA Server Best Practices Analyzer on each array member.

Checking mode completion issues

It is helpful to determine which mode of IPsec negotiation is failing—main mode or quick mode. There are a number of ways to check main mode or quick mode status or failure, including:

Enable auditing to ensure that IPsec-related events are logged.
Use IP Security Monitor to view IPsec information.
Use an Oakley log file. Note that Oakley log files do not exist on computers running the Microsoft Windows Server® Code Name "Longhorn" or Windows Vista™ operating systems.

Auditing IPsec events

Internet Key Exchange (IKE) events are written to the security log. (The IKE event category is also used for auditing logon events in services other than IPsec.) Administrators on the local computer can enable logging for the local computer as follows.

To enable logging for the local computer

In Control Panel, double-click Administrative Tools.
Double-click Local Security Policy.
In the console tree, expand Local Policies, and then click Audit Policy.
In the details pane, double-click Audit logon events. To audit successful attempts, select the Success check box. To audit unsuccessful attempts, select the Failure check box.

When you enable success or failure auditing, IPsec records the success or failure of each main mode and quick mode negotiation and the establishment and termination of each negotiation as separate events. However, enabling this type of auditing can cause the security log to fill with IKE events. For example, for servers that are connected to the Internet, attacks on the IKE protocol can cause the security log to fill with IKE events. IKE events can also fill the security log for servers that use IPsec to secure traffic to many clients. To avoid this, you can disable auditing for IKE events in the security log by creating the following registry key.

To disable auditing for IKE events in the security log

Click Start, and then click Run.
In the Open field, type Regedit, and then click OK.
Expand HKEY_LOCAL_MACHINE, expand System, expand CurrentControlSet, and then expand Control.
Right-click LSA, point to New, and then click Key.
Type the name DisableIKEAudits for the key.
In the details pane, right-click the default value, and then click Modify.
In Value Data, type 1, and then click OK.

Close the Registry Editor.

Note:
Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

After making this change to the registry, you must either restart the computer or stop and then restart the IPsec service by running the net stop policyagent and net start policyagent commands at the command prompt. Note that stopping and restarting the service may disconnect all computers using IPsec from the computer on which the service is stopped. For more information, see the topic "Stopping and restarting the IPsec service" in "IPsec Troubleshooting Tools" at the Microsoft TechNet Web site.

IP Security Monitor

In the Microsoft Windows Server 2003 and Windows® XP operating systems, IP Security Monitor is implemented as a Microsoft Management Console (MMC) snap-in. View the IP Security Monitor as follows.

To view the IP Security Monitor

Click Start, and then click Run.
In the Run dialog box, type MMC, and then click OK.
Click the File menu, and then click Add/Remove Snap-in.
In the Add/Remove Snap-in dialog box, click Add.
In the Add Standalone Snap-ins dialog box, select IP Security Monitor from the snap-in list, and then click Add. Click Close to close the Standalone Snap-in dialog box. Click OK in the Add/Remove Snap-in dialog box.
On the File menu, click Save to save the console settings and specify a name for the saved .msc console.
In the IP Security Monitor console, click Add Computer to add the local computer or a remote computer.
To view main mode details, expand the computer for which you want to view IPsec information, and then expand Main Mode. Expand Security Associations and verify whether there are associations between the two VPN endpoints.
Repeat the preceding steps for quick mode.

IP Security Monitor also allows you to view details about an active IPsec policy that is applied by the domain or locally, and to view quick mode and main mode statistics, as well as IPsec security associations (SAs). IP Security Monitor also enables you to search for specific main mode or quick mode filters. To troubleshoot complex IPsec policy designs, you can use IP Security Monitor to search for all matches for filters of a specific traffic type.

Oakley log file

Although enabling auditing, logging, and viewing IKE events in Event Viewer is the simplest way to troubleshoot failed main mode or quick mode negotiations, some scenarios may require a more detailed analysis. The IKE tracing log (systemroot\Debug\Oakley.log) is a detailed log for troubleshooting IKE interoperability. The log has a fixed size of 50,000 lines and will overwrite as necessary. Each time the IPsec service is started, a new Oakley.log file is created, and the previous version of the Oakley.log file is saved as Oakley.log.sav. When the Oakley.log file becomes full, it is saved as Oakley.log.bak, and a new Oakley.log file is created. Because many IKE negotiations can occur simultaneously, you should minimize the number of negotiations and logs for as short a period of time as possible to capture a more easily interpreted log. In Windows Server 2003, you can enable or disable the IKE tracing log dynamically while the IPsec service is running, as follows:

To enable IKE tracing, at a command prompt, type netsh ipsec dynamic set config ikelogging 1. This command creates the IKE tracing log file if it does not exist. If it already exists, it appends information to the existing log file.
To disable IKE tracing, at a command prompt, type netsh ipsec dynamic set config ikelogging 0.

Run the Oakley log while trying to connect to troubleshoot main mode and quick mode issues.

Interpreting logged events

If logged events indicate that Phase 1 Main Mode or Phase 2 Quick Mode has not completed successfully, view the main mode or quick mode settings by exporting the filters, with one of the following methods:

Use the command-line tool Netsh to export the mode filters and examine settings. To do this, type the following at a command prompt: netsh ipsec dynamic show all.
Alternatively, you can export the filters using IP Security Monitor, as follows:

In the MMC, open the IP Security Monitor .msc console.
Expand the local computer, and expand Main Mode.
Select Specific Filters, and on the Action menu, click Export List.
Repeat for quick mode.

For more information about main mode and quick mode, see "The IPsec process" at the Microsoft TechNet Web site.

Reading the Audit log

Success of IKE negotiation is noted in the Audit log. For the entire IPsec security negotiation to be successful, you need both a main mode SA established and a quick mode SA established. Possible reasons for failure include:

An IKE time-out occurs. IKE may time out during the initial negotiation request if routers in front of the VPN server are not configured to allow UDP port 500 through, or if an appropriate policy is not configured on the VPN server.
Certificate credentials do not work.
There is an issue with a manual IPsec policy.

Common issues

The following sections describe common issues.

Traffic is not sent and an error is issued in the Firewall log

Symptom: Traffic is not being sent to or from the IPsec network, and the following run-time error is returned in the Firewall log: FWX_E_Network_Rules_Denied.

Cause: There is no network rule configured between the local Internal network and the remote IPsec network.

Solution: ISA Server requires a network rule to specify that two different networks can communicate:

In ISA Server 2006, you can specify that ISA Server should create the network rule automatically when you run the Create Site-to-Site Connection Wizard to create a network object that represents the remote site Internal network. ISA Server only creates a network rule with a route relationship. Alternatively, you can select to create a network rule manually after completing the Create Site-to-Site Connection Wizard.
In ISA Server 2004, you must create a network rule manually after creating a network object to represent the remote VPN site. The network rule configures a relationship between the local Internal network and the remote VPN network.

Create a network rule manually as follows.

After creating a network object to represent the remote VPN IPsec site, do the following:

In the Configuration node of ISA Server Management, click Networks.
In the details pane, select the Network Rules tab.
On the Tasks tab, click Create a Network Rule.
On the Welcome page of the New Network Rule Wizard, click Next.
On the Network Traffic Sources page, click Add.
In the Add Network Entities dialog box, expand Networks.
Select Internal, and then click Add.
Click Close to close the dialog box.
On the Network Traffic Sources page, click Next.
On the Network Traffic Destinations page, click Add.
In the Add Network Entities dialog box, expand Networks.
Select the network object you created to represent the remote VPN network, and then click Add.
Click Close to close the dialog box.
On the Network Traffic Destinations page, click Next.

On the Network Relationship page, select Route.

Note:
When the two VPN networks have a route relationship, client requests from either network are directly forwarded to the other network, with the source and destination IP addresses unchanged. A route relationship is specified when IP addresses do not need to be hidden between networks. A route relationship is bidirectional. You have configured a route relationship from the local Internal network to the remote VPN network, and vice versa. For more information, see the topic "Network Rules" in "Network Concepts in ISA Server 2006" at the Microsoft TechNet Web site. The information is also applicable to ISA Server 2004.

Note:

When the two VPN networks have a route relationship, client requests from either network are directly forwarded to the other network, with the source and destination IP addresses unchanged. A route relationship is specified when IP addresses do not need to be hidden between networks. A route relationship is bidirectional. You have configured a route relationship from the local Internal network to the remote VPN network, and vice versa. For more information, see the topic "Network Rules" in "Network Concepts in ISA Server 2006" at the Microsoft TechNet Web site. The information is also applicable to ISA Server 2004.

Then click Next.
On the final page of the New Network Rule Wizard, check the configuration settings, and then click Finish to complete the wizard.
In ISA Server Management, click Apply to apply the changes.

Traffic to and from the IPsec network is denied by ISA Server

Symptom: Traffic sent to or from the IPsec network is denied by ISA Server. You can check this by setting up a log query to see whether traffic is being denied from a specific source or to a specific destination, and specify the remote IPsec server as the source or destination.

Cause: There is no access rule allowing hosts in the local Internal network and the remote VPN network to communicate.

Solution: In addition to a network rule specifying a relationship between two networks, ISA Server requires an access rule to specify that traffic can be exchanged between hosts in the different networks:

In ISA Server 2006, you can specify that ISA Server should create the access rule automatically when you run the Create Site-to-Site Connection Wizard to create a network object that represents the remote site Internal network. You must specify a name for a rule and the protocols to which the rule applies. Alternatively, you can select to create an access rule manually after completing the Create Site-to-Site Connection Wizard.
In ISA Server 2004, you must create an access rule manually after creating a network object to represent the remote VPN site, and a network rule to specify that the local Internal network and the remote VPN network can communicate.

Create an access rule manually as follows.

To create an access rule

Click the Firewall Policy node of ISA Server Management.
On the Tasks tab, click Create Access Rule.
On the Welcome page of the New Access Rule Wizard, click Next.
On the Rule Action page, click Allow.
On the Protocols page, select the protocols to which you want the rule to apply. You can select to apply the rule to All Outbound Traffic (all defined outbound protocols), or limit the rule to specific protocols to save VPN bandwidth. Then click Next.
On the Access Rule Sources page, click Add.
In the Add Network Entities dialog box, expand Networks.
Select the network object you created to represent the remote network, and then click Add.
Click Close to close the dialog box.
On the Access Rule Sources page, click Next.
On the Access Rule Destinations page, click Add.
In the Add Network Entities dialog box, expand Networks.
Select the Internal network, and then click Add.
Click Close to close the dialog box.
On the Access Rules Destinations page, click Next.
On the User Sets page, leave the default All Users setting to specify that the rule is anonymous. If you want to authenticate users for this access rule, click Add. Then in the Add Users dialog box, select All Authenticated Users, click Add, and then click Close.
On the User Sets page, click Next.
On the final page of the New Access Rule Wizard, check the configuration settings, and then click Finish to complete the wizard.
In ISA Server Management, click Apply to apply the changes.

Ping is denied between VPN network hosts

Symptom: Host computers in the local Internal network cannot use the ping command to find hosts in the remote IPsec network. Ping presents the message: "Negotiating IP security," and no reply is received.

Cause: This error appears in the following circumstances:

A computer in the ISA Server VPN network tries to use the ping command to find a computer in the remote VPN network.
When you defined the ISA Server VPN network on the remote computer, you did not include the VPN tunnel endpoint address of the ISA Server computer.
Or, alternatively:
A computer in the remote VPN network tries to use the ping command to find a computer in the ISA Server VPN network.
When you defined the remote site VPN network on the ISA Server computer, you did not include the VPN tunnel endpoint address of the remote VPN server.

Solution: Ensure that you add the VPN tunnel endpoint address when you define the remote VPN site on each side of the IPsec tunnel. For example, if the ISA Server computer is Server A, and a third-party VPN server is Server B, when you define the VPN network of Server A on Server B, include the address of the Server A VPN endpoint. When you create a remote network object to represent the remote VPN site in ISA Server Management, you can add this when you run the Create VPN Site-to-Site Connection Wizard. To add this after you have created the network object, do the following.

To add the remote VPN gateway to the remote VPN server address range

In ISA Server Management, click the Virtual Private Networks (VPN) node.
On the Remote Sites tab, right-click the remote network object you created to represent the remote VPN site, and then click Properties.
On the Addresses tab, verify that the IP address range includes the remote gateway IP address.

At the remote site, include the IP address of the ISA Server external interface in the network address range you configure for the ISA Server VPN site.

Traffic flow is not consistent

Symptom: Traffic does not flow from one IPsec network to another, but may pass in the opposite direction.

Cause: This may be caused by inconsistency between the actual range of a VPN network, and its definition on the other side. For example, the ISA Server VPN will try to negotiate an IPsec policy with the remote VPN site based on the IP address range and mask of the ISA Server VPN network. If the network range used in the policy negotiation does not match the ISA Server VPN network definition specified on the remote computer, the remote VPN server will fail to create an SA.

Solution: Verify the following:

When you define the remote VPN site on the local ISA Server computer, the IP address range you define must exactly match the remote VPN network range as it is defined on the remote computer.
When you define the ISA Server VPN network on the remote VPN device, the IP address range you define must exactly match the VPN network range of the ISA Server VPN network.

Quick policy mode negotiation fails with a "No policy configured" error

Symptom: An event is logged in the system event log, which indicates that quick policy mode negotiation failed with a "No policy configured" error.

Cause: The IPsec network range combines several physical networks with adjacent ranges. If you configure a remote site network, which actually comprises two different networks with adjacent IP address ranges in the same subnet, connections cannot be initiated to either network.

Solution: To avoid this, create two remote site IPsec networks, one for each physical network. Then create appropriate network and access rules for each remote site. For example, suppose you have three networks:

Network A with address range 10.1.0.0/24
Network B with address range 10.1.1.0/24
Network C with address range 10.1.2.0/24

To define remote site network connectivity from Network C to Network A and Network B, you must define two distinct remote networks (one for Network A and one for Network B), rather than combining the address ranges.

Also note that accurate network configuration is essential for IPsec site-to-site communications to work as expected. The VPN network on the local ISA Server computer (usually the default Internal network) must match the IP addresses of the network adapter associated with the network, and should include all subnets accessible from the adapter. Every time a network adapter receives a packet, ISA Server checks whether the source IP address of the packet is a valid address for the specific network adapter. If ISA Server does not consider it valid, an IP spoofing attack alert is issued. An IP address is considered valid if both of the following conditions are true:

The IP address resides in the network of the adapter through which it was received.
The routing table indicates that traffic destined to that address may be routed through the adapter belonging to that network.

An IPsec tunnel cannot be established through a NAT device or router

Problem: A VPN tunnel cannot be established through a network address translation (NAT) device or router.

Cause: Check whether the VPN IPsec traffic is going through a NAT device or a router. There are a number of problems using IPsec over NAT devices:

A NAT device changes packet information during the address translation process. The process can either fail because information needed by the NAT device for translation is encrypted, or the encrypted packet is considered invalid by IPsec.
NAT traversal (NAT-T) overcomes these issues by allowing IPsec peers behind NAT devices to detect the presence of NAT devices, negotiate IPsec SAs, and send ESP-protected data, despite the fact that the addresses are changed by NAT.
Solution: Consider the following:
When the remote VPN device is a computer running Windows 2000 Server with Routing and Remote Access or ISA Server, by default, NAT traversal (NAT-T) is not supported, and you cannot establish a VPN tunnel to such a device. The VPN gateways must be running Windows Server 2003 for NAT-T support.
The NAT device must be configured to forward traffic from UDP port 500 (IKE traffic) and UDP port 4500 (IPsec NAT-T traffic) to the external network interface of the ISA Server computer.
If there is a router in front of ISA Server, ensure that traffic to UDP port 500 (IKE traffic) and IP protocol 50 (ESP-protected traffic) can pass between the ISA Server VPN and the remote VPN endpoint.

Traffic does not flow between IPsec networks, and NLB is enabled

Symptom: Network Load Balancing (NLB) is enabled on the local ISA Server network or the remote IPsec network, and a connection cannot be established, or traffic is not flowing as expected.

Cause: If NLB is enabled, the initial VPN connection from the ISA Server VPN will be to the virtual IP address of the computer. Then the IPsec tunnel will be established from one of the dedicated IP addresses on the VPN network. This is because the source IP addresses for HTTP proxy and NAT traffic from VPN sites are subject to address translation (on the remote side). One side of the VPN tunnel therefore sees the traffic as if it is arriving from the primary IP address of the remote site—that is, from its dedicated IP address. IP addresses are translated to dedicated IP addresses and not to virtual IP addresses because ISA Server takes the first IP address for the network card, which is the dedicated IP address and not the virtual IP address.

Solution: Ensure the following is configured:

If the remote site has load balancing enabled, specify the following:
Specify the virtual IP address of the remote VPN site as the remote tunnel endpoint when you configure a remote network object to represent the remote VPN site in ISA Server.
Ensure that the virtual IP address is included in the IP address range of the remote VPN network that you define in the remote site network object you configure on the local ISA Server computer.
Include all the dedicated IP addresses of the remote external adapter in the IP address range of the remote site network object you configure on the local ISA Server computer. You can add this when you run the Create VPN Site-to-Site Connection Wizard. To add this after you have created the network object, do the following.
To add the dedicated IP address to the remote VPN server address range
1. In ISA Server Management, click the Virtual Private Networks (VPN) node.
2. On the Remote Sites tab, right-click the remote network object you created to represent the remote VPN site, and then click Properties.
3. On the Addresses tab, verify that the dedicated IP address is included in the IP address range.
If the local ISA Server network containing the local tunnel endpoint (usually the External network) has NLB enabled, specify the following:
Specify the virtual IP address as the ISA Server VPN tunnel endpoint on the remote VPN server.
Ensure that the virtual IP address is included in the IP address range of the ISA Server local VPN network that you define on the remote VPN server.
Include all the dedicated IP addresses of the ISA Server network adapter listening for IPsec requests in the IP address range of the ISA Server VPN that you define on the remote VPN server.

IPsec main mode cannot complete because settings do not match

Symptom: Main mode cannot complete. IPsec main mode establishes a secure channel for authentication.

Cause: Main mode settings on the ISA Server computer and the remote VPN IPsec server do not match.

Solution: Verify that the following main mode settings match on both sides of the VPN IPsec site-to-site network:

Encryption algorithm (DES, 3DES)
Integrity algorithm (MD5, SHA1)
Diffie-Hellman group (Group 1 - 768-bit, Group 2 - 1024-bit, Group 2048 - 2048-bit). Note that 2048-bit is not supported on Windows 2000 Server.
Key lifetime (seconds)

IPsec quick mode cannot complete because settings do not match

Symptom: Quick mode cannot complete. IPsec quick mode establishes a secure channel for traffic protection.

Cause: Quick mode settings on the ISA Server computer and the remote VPN IPsec server do not match.

Solution: Verify that the following quick mode settings match on both sides of the VPN IPsec site-to-site network:

Encryption algorithm (DES, 3DES)
Integrity algorithm (MD5, SHA1)
Key lifetime (kilobytes)
Key lifetime (seconds)
Enable Perfect Forward Secrecy (PFS)
Diffie-Hellman group (Group 1 - 768-bit, Group 2 - 1024-bit, Group 2048 - 2048-bit). Note that 2048-bit is not supported on Windows 2000 Server.

Quick mode may also fail due to an invalid network filter list or access control list (ACL) specified on one side of the VPN tunnel.

A connection cannot be established between the local and remote VPN servers. A preshared key is used for authentication

Symptom: A connection cannot be established between remote and local VPN servers.

Cause: Preshared keys are not identical on the local ISA Server VPN and the remote IPsec server.

Solution: Modify the preshared key value so that they match on the local ISA Server VPN and the remote IPsec server.

Main mode cannot be established. Certificates are used for authentication

Symptom: Main mode cannot be established.

Cause: The same certification authority (CA) is not selected on both sides of the VPN tunnel.

Solution: Ensure that on both sides of the tunnel, the same CA is selected to issue the certificate used for connection authentication. On the ISA Server computer, you select the CA that you expect to issue the IPsec certificate when you run the Remote Site Network Wizard to create a remote network object to represent the remote IPsec network. After running the wizard, you can change the CA by modifying the properties of the remote site network created with the wizard, as follows.

To modify the CA

In ISA Server Management, click the Virtual Private Networks (VPN) node.
On the Remote Sites tab, right-click the remote network object you created to represent the remote VPN site, and then click Properties.
On the Authentication tab, click Browse, and select a CA from the list.

Note:
We recommend using a private CA to issue the IPsec certificate.

Note:
We recommend using a private CA to issue the IPsec certificate.

Cause: Certificates with the Intended Purposes field set to IP security IKE intermediate or Any, and issued by the CA specified in the remote site network properties cannot be found in the Local Computer store. The IPsec certificate in the Local Computer store must be issued by the CA specified on the Authentication tab in the properties of the remote site network you create to represent the remote VPN site.

Solution: Check that an IPsec certificate has been issued by the CA you selected, and that it is present in the Local Computer store. If not, request a certificate of this type from the CA, and install it in the Local Computer store.

Cause: A trusted root certificate for the issuing CA is not installed in the Trusted Root Certificate store on the local and remote VPN servers. Each side of the IPsec tunnel must trust the certificate used by the other side to authenticate the connection.

Solution: Ensure that the local ISA Server VPN has a trusted root certificate for the CA that issued the certificate used by the remote server for authentication. Ensure that the remote server has a trusted root certificate for the CA that issued the certificate used by the local ISA Server VPN for authentication.

Cause: The root certificate for the issuing CA is invalid or has been revoked.

Solution: In the Local Computer Certificates store, check the properties and validation of the certificate. Obtain a new IPsec certificate if required.

When you use a certificate to authenticate VPN connections, ISA Server automatically enables a system policy rule that allows the latest certificate revocation list (CRL) to be downloaded to ISA Server. By default, this CRL check is skipped if the download fails or takes longer than 10 seconds. This could potentially result in a compromised certificate. To avoid this issue, you can specify that the VPN tunnel cannot be established if the CRL is inaccessible. To do this, you set the IPsec StrongCRLCheck value using either Netsh or a registry key, as follows:

At a command prompt, type the following: netsh ipsec dynamic set config strongcrlcheck value=2. This change is not persistent, and it is only valid for the current session.
Alternatively, under the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\ key, add a new Oakley subkey, with a DWORD entry: StrongCRLCheck, and assign it a value of 2. Then restart the Policy Agent service and the Microsoft Firewall service. This setting is persistent.

Note that over a slow link, setting StrongCRLCheck to 2 can result in a failed VPN connection if ISA Server does not get a response from the CA in time. Other alternatives to make the CRL available include publishing the CRL to the Internet. For more information, see "Revoking certificates and publishing CRLs" at the Microsoft TechNet Web site. Alternatively, you could add an additional CRL distribution point to the CA certificate. For more information, see the Microsoft Knowledge Base article 232161 "Changing the Locations of Your Certificate Revocation List (CRL) in Certificate Services 2.0."

Cause: The IPsec certificate in the Local Computer store does not have a corresponding private key. The private key is required for authentication of the local site to the remote site. This issue occurs when the private key is not exported together with the public key.

Solution: Re-create the certificate, or export it again and import it together with the private key.

Traffic cannot be routed from the ISA Server computer to the remote VPN site

Symptom: Traffic is not routed to the remote VPN site.

Cause: The network adapter that listens for site-to-site VPN connections from the remote site network (usually the External network) does not have a default gateway configured.

Solution: To correct this error, define a default gateway that is not a local address for the network adapter that listens for site-to-site VPN connections. Note that ISA Server does not support multiple default gateways. Set a default gateway on only one of the network adapters associated with ISA Server networks, and do not configure more than one default gateway on that adapter.

Manage Your Profile | Contact Us | Newsletter

Product Families

Resources

About Microsoft

Popular Places

Popular Searches

Popular Downloads