|
||||||
|
 |
|
  |
|
  |
|
|
[ Notify if New Document is Added to Info Docs Collection ] [ View/Edit Notifications ] [ View/Edit Marked Documents ]
Disclaimer: This document is not intended to be a substitute for the SunScreen 3.2 documentation or Microsoft documentation, but rather as an abbreviated overview on setting up IKE between these two products. There are many variations not shown here that should also work. The procedures below will give the reader a basic background for deployment. Discussion of the IKE protocol and the meaning of the basic IKE parameters will not be covered. The examples will assume Windows 2000 system, but the Windows XP interface should be nearly identical.
SunScreen supports IPsec/IKE with
Windows 2000 and XP support IKE with
Windows and SunScreen both support IKE in either Transport or Tunnel mode. Based on the above information, Windows IKE can interact with SunScreen IKE using Pre-shared keys or CA-signed certificates (RSA-MD5 or RSA-SHA1) for normal connections, and CA-signed certificates only for remote administration connections. In the case of CA-signed certificates, the certificate on each system must be signed by a common root CA. - Click Start->Run..., type mmc A window will appear, labeled Console1, with a subwindow labeled Console Root. - Click Console->Add/Remove Snap-in - Click "Add..." and add the following snap-ins: Certificates: Choose Computer Account, Local Computer IP Security Policy Management: Choose Local Computer - Click OK, then Console->Save to save these settings. The following example is the simplest IKE connection scenario. This setup is useful for getting familiar with the administrative interfaces of both systems. Windows 2000 System IP address = 129.148.176.205 SunScreen IP address = 10.8.20.34 Windows System Setup: - Open "IP Security Policies on Local Machine". These policies can most easily be accessed through "mmc" but are also available through: Control Panel-> Administrative Tools ->Local Security Policy, click on "IP Security Policies on Local Machine" With "mmc", there will be more options for troubleshooting later, so this example will use that method. Open "Console1", as created above. - Create a new security policy There will be three default policies listed: Client, Secure Server, and Server. We will create a new custom policy. Click Action-> Create IP Security Policy. The IP Security Policy wizard will appear. Click Next, name the policy, and click Next again. Uncheck "Activate the default response rule" and click Next. Click Next. Leave "Edit properties" checked and click "Finish". Click "Add..." and then Next. Since we are using Transport mode for this example, click the radio button entitled "This rule does not specify a tunnel". Click Next, Select "All network connections", and click Next again. Click the radio button labeled "Use this string to protect the key exchange (preshared key)" and enter a string. Click Next, then choose Add to add a new filter. Name the filter and click "Add..." again. A wizard will appear. Click Next. Choose "My IP Address" as the source address. Click Next and choose "A specific IP address" as the destination address. Enter the IP address. Click Next, then Select protocol type "Any". Click Next again. Click Finish. There will be a be a new IP filter, listed as "Mirrored". Click "Close" Check the radio button for your new policy, then click Next. Click Next, then click "Require Security". (Do not click Next yet). Click "Edit..." and uncheck "Accept unsecured communication, but always respond using IPSec". Click OK, then Next, then Finish. There will be a new filter listed and checked. Click Close. Right-click on the new policy and choose "Assign". The Windows system should be ready to go at this point. SunScreen system setup: - Create a new policy or edit the existing policy. - Create an address object for both the Screen and the Windows system. In our example, the objects will be called "togatoga" and "win2k" respectively. - Create a new IPsec Key. This will be the pre-shared key. For SunScreen, we must use the ASCII equivalent of the key we entered in the Windows configuration, therefore the key "thisisabadkey" becomes 0x746869736973616261646B6579. - Create a rule allowing the services that will be encrypted. The source will be win2k, destination togatoga and action ENCRYPT. - Choose encryption type "IPSEC IKE". Set some suitable parameters. For this example, we will use: ESP = 3DES, SHA1, AH = NONE IKE = 3DES, SHA1, 2, PRE-SHARED, Preshared Key = preshared_key. Note: For these parameters, Oakley group 2 must be used if the defaults are to be used on Windows. To view the Windows defaults, go to the IPsec Policy, General Tab->Advanced->Methods page. The defaults are: Table 1.
Oakley group 5 is not supported by Windows. Also, Oakley group is referred to as Diffie-Hellman group in the Windows interface. - Click on the options tab and click "Transport Mode". Choose the Screen for the Destination Screen parameter. - Click OK and save and activate the policy. - Test the encrypted connection, running snoop to verify that IKE is working. The simplest way to obtain a CA-signed certificate with Windows is by using another Windows system. The first example will be to get a certificate signed by a departmental Windows Certificate Authority. The software comes as part of Windows 2000 Server and Advanced Server. Please consult the documentation on how to set this server up. - Connect to the server with Internet Explorer. The URL will be http://servername/certsrv/ - Click "Request a certificate", then click Next. - Click "Advanced Request", then click Next. - Click "Submit a certificate request to this CA using a form", then click Next. - Create a Certificate Request, creating a new key set and using the local machine store. This will store the private key in the machine's key store. An example follows. - Click "Submit". If the server is set up to automatically issue certificates, you will be prompted to install the certificate. If not, go back to the web site when the certificate is issued. - Chose "Install this certificate" and the certificate will be automatically added to the local machine's keystore. You must also add the root certificate of the signer to the list of Trusted Root CAs. Go back to http://servername/certsrv/ and click "Retrieve the CA certificate or certificate revocation list" Click on "Install this CA certification path" to make the CA trusted. You will be prompted to add the certificate to the Root Store. To verify that everything has gone smoothly, open mmc and the console you have been working on (Console1 in this example). Go to Certificates. The root CA certificate should be located under Trusted Root Certification Authorities or Intermediate Certification Authorities. Your signed certificate should be listed under Personal->Certificates. Double-clicking on it should indicate that there is a private key that corresponds to the certificate and the certification path should show OK. An example follows: In this example, we will use a Netscape CMS server as the Certificate Authority. This procedure would work just as well to a commercial CA. In that case, it might not be necessary to import the root CA's certificate, as there are several root certs preinstalled in the Windows Certificate Store. As far as the author is aware, there is no straightforward way to generate a private key and a CSR (certificate signing request) without using the Microsoft Certificate Services or installing a web server. Any information to the contrary would be greatly appreciated. It is possible to import a key and certificate pair in .p12 format if that method is desired. This example will show how to generate a request on behalf of the client. - Connect to the Windows CA server at http://servername/certsrv/ as in the previous example. - In the form, choose "Use local machine store" and "Save request to a PKCS#10 file". The effect of these actions will be to generate a private key and put it in the local keystore and the generation of a CSR in standard format that can be sent to any CA. No issuance request will be made to the local CA. The CSR is now ready to send to a certificate authority. An example with Netscape CMS follows. Procedures will be similar for any commercial CA. - Click on SSL Server. Cut and Paste the CSR request from the file just generated and click Submit. Take note of the request number. - Wait for email confirmation that the certificate has been issued and then go to the Retrieval tab. Enter the request number to retrieve the certificate. Copy the PKCS7 encoded certificate chain to a file. - Go to mmc->Certificates->Personal->Certificates. Right click and choose All Tasks->Import... - Find the certificate file and Place it in the Personal Certificate store. You will see two new certificates installed in the certificate store. One is the system's signed certificate and one is the Root Certificate of the CA. - Move the Root CA certificate to the Trusted Root Certificates->Certificates folder. - Double-click on the system's issued certificate and verify its integrity, as in the previous example. The author considers this method to be the most secure since the Windows administrator has complete control of the private key at all times. Download the OpenSSL bundle for Windows. There are several precompiled versions available on the Internet. The OpenSSL zip file from the Apache modssl distribution is the easiest to install on Windows, as it extracts all precompiled binaries and libraries into one directory. The example will assume that you have downloaded this distribution and extracted all of the files into one directory. For simplicity, this example will also create all configuration, input, and output files in this same directory. - Go into the openssl directory. - Create a skeleton configuration file called "openssl.cnf", for example: [req] distinguished_name = req_distinguished_name [req_distinguished_name] C = US ST = MA L = Burlington O = Sun Microsystems OU = QA CN = Win2K Admin emailAddress = testuser@sun.com - Create a private key and CSR: C:\openssldir> openssl req -config openssl.cnf -newkey rsa:1024 -keyout key.pem -out req.pem Explicitly type in all of the values for the Distinguished Name. Do not just hit return for the defaults, even if they are the same values! You will have a private key on your system in this directory (key.pem) and a CSR (req.pem). Treat the key.pem as sensitive information. This is your private key! - Send the "req.pem" file to a CA to be signed. Follow example 2 above for a Netscape CMS server. - Retrieve your signed certificate and place it in the openssl directory. This example will assume the file is called "signedcert.crt". - Merge the private key and signed certificate into a pkcs12 file by running the "openssl pkcs12" command, e.g.: C:\openssldir> openssl pkcs12 -export -inkey key.pem -in signedcert.crt -out combined.p12 - Import the certificate into the Personal keystore with mmc -> Certificates -> Personal -> Certificates. Right-click and choose import. Browse to the pkcs12 file (combined.p12) and import it. You should also import the CA root certificate as in example 2 above. Verify the certificate by double clicking on it, making sure that it has an associated private key and that the certificate path is OK. It is probably wise to delete all of the key and certificate files from the the openssl directory once the key and certificate have been imported. - Bring up a policy in the GUI. - Click Certificate->Generate IKE Certificate - Click "Generate CA Request" - Enter a Distinguished Name and choose type rsa-md5 or rsa-sha1. For example: - Click Generate. A private key will be generated and stored in the local database. A CSR request will appear. Cut and paste it into a file. - Bring this CSR request to the web page of a CA. Following the example above, we have for the Microsoft CA: - Request a certificate->Advanced Request->Submit a certificate request using a base64 encoded PKCS#10 file... - Cut and paste the CSR into the form and click Submit. - When the certificate is issued, Click Download CA certificate (in Base 64 encoded format), and save this file somewhere. - Go back to the SunScreen GUI and go to Certificate->Import IKE Certificate. - Give the certificate a name (this is just a handle for use in SunScreen) and paste in the the text from the file. - Click Install Certificate. A dialog indicating success should appear. - Go back to the Windows CA server and click "Retrieve the CA certificate or certificate revocation list" and download the CA certificate, Base 64 encoded. - Go to the SunScreen GUI and select Certificate Import IKE Certificate. Install this certificate as above. - Go to Certificate->Search to list the certificates in SunScreen. There will be a special group called "IKE root CA certificates". Select this group from the pull-down and click "Edit". Add the Root CA Certificate to the Include list. This group is similar to the Trusted Root Certificate Store in Windows. Following the example above for the Netscape CMS CA, we have: - Click on "SSL Server" and cut and paste the CSR into the PKCS#10 Request form. Fill out the contact information and click Submit. Take note of the request number. - When you receive notification that the certificate has been issued, go to Retrieval and enter your request number to retrieve the certificate. Copy and paste the Base 64 encoded certificate into a file. - Go to the SunScreen GUI and and go to Certificate->Import IKE Certificate. - Give the certificate a name (this is just a handle for use in SunScreen) and paste in the the text from the file. - Click Install Certificate. A dialog indicating success should appear. - Go back to the Netscape CMS server and Click Retrieval->Import CA Certificate Chain->Display Certificates in the CA certificate chain for importing individually into a server. Click Submit. Cut and paste the Base 64 encoded certificate into a file. - Go to the SunScreen GUI and select Certificate Import IKE Certificate. Install this certificate as above. - Go to Certificate->Search to list the certificates in SunScreen. There will be a special group called "IKE root CA certificates". Select this group from the pull-down and click "Edit". Add the Root CA Certificate to the Include list. - Save the changes to the policy and test the connection. This example will assume a Windows system with an arbitrary IP address, a SunScreen with a static "Internet" facing address of 10.8.20.34 and a private "internal" network of 192.168.7.0/24. Windows setup: Follow the basic steps of the pre-shared key example above, with the following changes: - When asked whether this rule specifies a tunnel, click "The tunnel endpoint is specified by this IP address". Fill in the "Internet" facing IP address of the SunScreen. - Continue through as in the pre-shared key example until reaching the "Authentication Method" page. - Select "Use a certificate from this Certificate Authority (CA):" and click browse. - Select the certificate of the Root CA that signed your certificate. Note that there will not be a list of your system's certificates, only those of the CAs. The Windows system will automatically select its own certificate that was signed by this CA when the IKE negotation happens. - Click Next and continue on to the "IP Filter List" page. Create a new IP filter as in the pre-shared key example, with the following change. - At the "IP Traffic Destination" page, select "A specific IP Subnet" as the Destination address and fill in the "internal network". -When you are done, edit the Filter and uncheck the "Mirrored" box. - Keep filling out the forms as before, select the new IP filter's radio button and click Next, continuing on as in the preshared-key example. - Now create a another IP filter list, as above. This filter will be for the opposite tunnel direction. The tunnel endpoint this time will be the IP address of the Windows system. The Microsoft documentation explains that IPsec tunneling is meant for static IP addresses. If the IP address of the system changes periodically, this value will also have to be changed, unfortunately. Transport mode would not require this configuration change, but would have to assume Internet routable addresses internally. The author is not aware of any way around this limitation. - Choose the same values as before for the Certificate, etc. - Create a new filter with the opposite source and destination addresses, and uncheck the mirror box. Select this new filter and continue on as before. When you are finished, you should have two rules checked, each the mirror image of each other, both in filtering rules and tunnel addresses. - Be sure to assign this new security policy as active. SunScreen setup: - Create the following address objects, if not already defined: "internal-network" - an object with the addresses in the internal network (192.168.7.0/24 in this example) "Internet" - everything except the local addresses, i.e. include "*", exclude "internal-network" and any other SunScreen IP addresses. - Create an object for the Windows IKE certificate. - Click Certificate->Associate IKE Certificate - Give the object a name. This is just the "handle" for use in SunScreen. - Enter the Distinguished Name of the certificate. This can be found in Windows by double-clicking on the certificate and viewing "Subject "in the Details tab. For example, in Windows: The Distinguished Name should be entered in the format: SUBJECT=CN=name<space>,...,C=country. Note that the output on this screen may not be entirely accurate. The "S" may be "ST" and the "E5 may be "MAILTO". The ordering is also backwards. So the Distinguished Name above would be entered in SunScreen as "SUBJECT=C=US, ST=ma, L=burlington, O=sun, OU=qa, MAILTO=fakeemail2@sun.com, CN=Test User 2". Do not put quotes around the name in the GUI. For example... It is extremely important that the Distinguished Name be entered EXACTLY correctly, or the IKE negotiation will fail! Please reference the troubleshooting document for information regarding verification of Distinguished Names. - For scalability, create a new certificate group and add this certificate to that group. In this example, we will call the group "Internet-certs". - Create a rule allowing these services into the local network in a tunnel. The source address would be Internet and the destination address would be the internal network. - In the IKE window, choose "Internet-certs" as the source certificate and the SunScreen's certificate (signed by the same CA) as the destination certificate. The Authentication Method should be RSA-SIGNATURES, as that is the Windows compatible choice. Algorithm choices should follow the same principles as in the pre-shared key example. A sample screenshot follows... - Click on the "Options" tab and choose "Tunnel Mode". The Source Tunnel field should be blank, as the Windows systems will be using their actual IP addresses. The Destination tunnel should be the address object for the "Internet" facing address of the SunScreen. The Destination Screen should be set to the SunScreen. For example: - Save the rule and save, activate the policy, and test the connection to the internal network. This example will use a Windows system as a remote admin station in Transport mode. It will assume a dynamic IP address. Windows setup: Create a new IP Security policy in "mmc". Follow the example instructions for pre-shared keys above, with the following exceptions: - If there is a separate administrative interface, use that as the IP address (we will use the same address, 10.8.20.34, for this example). - Instead of choosing pre-shared keys, choose "Use a certificate from this Certificate Authority (CA):", as in the previous certificate examples. Remember, remote administration with IKE is only allowed with certificates. SunScreen setup: - Edit the policy you wish to remotely administer. - These instructions assume the existence of some SunScreen objects that were created in the IKE punch-in example. Refer to those instructions for more details. - Edit the existing screen object by pulling down to "Screen", clicking "Search", pulling down to the object, and clicking Edit. Click on the "Primary/Secondary" tab. If you wish to limit what IP address can be used for administration, pull down on "Administrative IP Address" and select an address. Pull down on "IKE Administrative Certificate" and select the screen's CA signed certificate". For example: - Click OK tochange the screen object. - Click on "Administrative Access". Add a new access rule for Remote Administration. The Screen object should be the screen. The address object should be "Internet" (this can be any address you choose if you wish to limit by IP address as well). Choose appropriate IKE parameters, using the Windows CA signed certificate as the Source Certificate. Note that the Destination Certificate field is grayed out. The Destination Certificate is the IKE Administrative Certificate defined in the screen object above. - Click on the Options tab and select "Transport Mode". Click OK, save the changes and activate. - To test, bring up a browser on the Windows system and connect to http://screen_ip_address:3852/. Be sure to have proxying turned off in the web browser. When associating IKE certificates, the previous examples used "SUBJECT=" when defining the Distinguished Name. Naming a certificate in this manner allows access by that one particular certificate. It is possible to define an IKE certificate association with "ISSUER=CA_Distinguished_Name", where CA_Distinguished_Name is the Name of the CA that signed a certificate. This kind of scenario is sometimes used for scalability, for example, trust all certificates signed by the departmental CA server. By doing this, an entry for each individual certificate is not needed. While this setup requires less administration, the security implications make it less than desirable and we recommend against it. All of the operations shown in the SunScreen GUI can also be done via command line. The command line method has a few more steps and is more error-prone, due to possible typographical errors, however it is a viable alternative to the GUI. This article will briefly describe some common operations. Creating a CSR for a CA-signed certificate: Use "ssadm certlocal" to create a private key and CSR, for example: # ssadm certlocal -Ikc -m 1024 -t rsa-sha1 -D "CN=SunScreen Admin, OU=QA, O=Sun Microsystems, C=US" Generating, please wait... Certificate Request generated. -----BEGIN CERTIFICATE REQUEST----- MIIBqjCCARMCAQAwTzEYMBYGA1UEAxMPU3VuU2NyZWVuIEFkbWluMQswCQYDVQQL EwJRQTEZMBcGA1UEChMQU3VuIE1pY3Jvc3lzdGVtczELMAkGA1UEBhMCVVMwgZww DQYJKoZIhvcNAQEBBQADgYoAMIGGAoGAarCSdUusFk0x/DnMNnSfdMmq8DuAFln0 U+5SF15MmN4bb+EKI9LaHwNOvisnPpgHtksAqu1HdCANz3zD4MQSY6Fx3dXo0nBm 2jpo6xhofMSawCcgd5U60LubAKytQEwgvUMaq7QigvwQy+TGtQTfDwHLMSdcbANr MbO/JCp5BbMCASWgHjAcBgkqhkiG9w0BCQ4xDzANMAsGA1UdDwQEAwIFoDANBgkq hkiG9w0BAQUFAAOBgQA6Xg7VrF6MFG62k7e+vKkmwl5yOoimdj6ypA8ANVM41dcQ ZoeJiCYAOg+DwxXTUkkaJQyCTAAUef7Rq6JSXeD7OOq5O6KXuxlgwapOtIzijw/V n/Erm6sydqaqp9Vaoc7AV4yZpuoBSGVyekbfRJ4Cq7Zj6iF/Rox+v6NyTIuQeg== -----END CERTIFICATE REQUEST----- # The above operation will create a private key in the SunScreen database. The output is suitable for cutting and pasting for submission to a CA. Importing a certificate: Importing a certificate on the command line takes two steps. Step 1: Import the certificate into the SunScreen database You shouldhave an ASCII certificate file, i.e. something like this: # more /tmp/cert -----BEGIN X509 CERTIFICATE----- MIIC6TCCAlKgAwIBAgIBBzANBgkqhkiG9w0BAQQFADBMMQswCQYDVQQGEwJVUzEZ MBcGA1UEChMQU3VuIE1pY3Jvc3lzdGVtczELMAkGA1UECxMCUUExFTATBgNVBAMT DFN1blNjcmVlbiBDQTAeFw0wMjAzMjAxMzU4MzdaFw0wMzAzMjAxMzU4MzdaMEIx ETAPBgNVBAMTCHRrLWhvc3QyMRkwFwYDVQQKExBTdW4gTWljcm9zeXN0ZW1zMRIw EAYDVQQGEwlBcmdlbnRpbmEwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIB AQCTSO+mvj6m+Tq3UfcDBQaUew8KbGDvf3JzjsobwaTu/xujhGb5langMQnlQhkD OMgdPfbEXiRX+DYYRIvQIR3d6lOYrkbol3PVSu8xrjbqVg++5hQW4EYI+mPk8NAA Bs4tGCHmA8DPAm31xS0CCGVCra9TVGsAFyu1kviZnzuqxmFXAeLCoi6eht+vnFKT NTpvfll/xC1eBZUT9uHFz8F1kjRQLrSUgmtchw/jWBL6m6ANEolOOP+PNhTaFymQ QbEibppmxfXolR8LcAd04L44Hemf+yyoZud/LirKGQYPz68qbboRHMnH8sYskoG8 U0+I6Q40u5o2wWUMHpQZpUXJAgEjo2MwYTALBgNVHQ8EBAMCBaAwEQYJYIZIAYb4 QgEBBAQDAgQQMB8GA1UdIwQYMBaAFN0avDR+aWhxBZdWhmbLYWWnu1HKMB4GA1Ud EQQXMBWBE21pY2hhZWwubGltQHN1bi5jb20wDQYJKoZIhvcNAQEEBQADgYEAh9wg skwfuMG4h4FszZ8kc0WZ/cd/G/8KZ4Jswu5N3OUaIy+veIlgDrxAJw/F38pvkMAI tl4Hc0huxIXuuc/afh3TuzVAynYwqaL6D29aHFx0XZGav5IxaU/fe03CxL2I+kM0 VGoyJtU5YyMQpiOanqJzz8vdBlGcbxTA947NkeQ= -----END X509 CERTIFICATE----- Use the "ssadm certdb" command to import the file, for example: # ssadm certdb -Ia < /tmp/cert # Step 2: Create a SunScreen object associated with this certificate. The Distinguished Name string must be entered exactly, so confirm the same first with "ssadm certdb"... # ssadm certdb -Il Certificate Slot Name: 4 Type: if-modn Subject Name: <CN=tk-host2, O=Sun Microsystems, C=Argentina> Key Size: 2048 Public key hash: 459BC59799FCF7C01B37B9C1A2457154 # Then add the certificate with your choice of object name and the exact Distinguished Name, e.g. edit> add certificate "tk-host2-cert" SINGLE IKE "SUBJECT=CN=tk-host2, O=Sun Microsystems, C=Argentina" If it is your own certificate (i.e. you have the private key), add "LOCAL screenname" at the end, for example: edit> add certificate "togatoga-CA-signed" SINGLE IKE CN=SunScreen Admin, OU=QA, O=Sun Microsystems, C=US" LOCAL "togatoga" Adding a certificate to the proper group: Any CA root certificate must be added to the "IKE root CA certificates" group in order to be trusted. Assuming you imported a root certificate and called it "myCA-root", an example would be: edit> add_member certificate "IKE root CA certificates" "myCA-root" Exporting a certificate: The ssadm certdb command can also be used to export a certificate. For example: # ssadm certdb -Ie "CN=tk-host2, O=Sun Microsystems, C=Argentina" > /tmp/cert Sample rules: IKE rules can get very long and cumbersome on the command line. Here are some example rules to help with the syntax. Please refer to the man pages for more information. IKE with pre-shared keys in Transport mode: # ssadm edit ike-preshared-transport -c "list rule 1"
1 "ftp" "win2k" "togatoga" IPSEC ESP("3DES", "SHA1") IKE("3DES", "SHA1", 2, PRE-SHARED,
"preshared_key") TRANSPORT DESTINATION_SCREEN "togatoga" ALLOW
IKE with certificates in tunnel mode: # ssadm edit ike-cert-tunnel -c "list rule 1"
1 "ftp" "Internet" "internal-net" IPSEC ESP("3DES", "SHA1") IKE("3DES", "SHA1", 2,
RSA-SIGNATURES, "Internet-certs", "togatoga-Netscape-issued") DESTINATION_TUNNEL
"togatoga" DESTINATION_SCREEN "togatoga" ALLOW
IKE remote admin rule # ssadm edit ike-remote-admin -c "list screen"
"togatoga" ADMIN_IP "togatoga" IKE("togatoga-Netscape-issued") CDP DNS NIS
# ssadm edit ike-remote-admin -c "list accessremote"
1 SCREEN "togatoga" USER "admin" "Internet" IPSEC ESP("3DES", "SHA1")
IKE("3DES", "SHA1", 2, RSA-SIGNATURES, "win2k-Netscape-cert") TRANSPORT PERMISSION ALL
Due to space constraints, troubleshooting IKE connections is covered in another article, Infodoc 47821. All references to 'Windows', 'Windows 2000', or 'Windows XP' refer to the Microsoft (R) Windows operating system, Microsoft (R) Windows 2000, or Microsoft (R) Windows XP respectively. Screen shot(s) reprinted by permission from Microsoft Corporation Top | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
