Example: Configuring the PKI in Junos OS

This example shows how to configure, verify, and troubleshoot the PKI. This topic includes the following sections:

Requirements

This example uses the following hardware and software components:

Network Topology

Figure 1 shows the network topology used for this example to configure a policy-based VPN.

Figure 1: Network Topology Diagram

Image g040512.gif

Note: The PKI administration is the same for both policy-based VPNs and route-based VPNs.

This example assumes the following settings:

Note: For more information about the procedures for PKI administration and usage in Junos OS, see the Junos OS Security Configuration Guide.

Note: For more information on using a CA from PKI vendors such as Microsoft and OpenSSL, see Appendix B: Administering Common Certificate Authorities.

Note: More information about PKI configuration with SSG5 and other Juniper ScreenOS-based platforms. see the Juniper Networks PKI (Public Key Infrastructure) Primer & FAQ, Using X.509 Certificates in ScreenOS.

Configuration

This topic includes the following section:

Basic Configuration Steps for PKI

Step-by-Step Procedure

  1. Configure an IP address and protocol family on the Gigabit Ethernet interfaces (ge-0/0/0.0 and ge-0/0/3.0):
    [edit]user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24user@host# set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30
  2. Configure a default route to the Internet nexthop:
    [edit]user@host# set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1

    In this example, the VPN traffic is incoming on interface ge-0/0/0.0 with the nexthop of 1.1.1.1. Thus the traffic is outgoing on the interface ge-0/0/3.0. Any tunnel policy must consider incoming and outgoing interfaces.

    Note: Optionally you can use a dynamic routing protocol such as OSPF (not described in this document). When processing the first packet of a new session, the Junos device first performs a route lookup. The static route, which is also the default route, dictates the zone for the outgoing VPN traffic.

  3. Set the system time and date.
    [edit]user@host# set system time-zone PST8PDTuser@host# commit and-quitcommit completeExiting configuration mode

    user@host> set date ntp 130.126.24.24
    1 Nov 17:52:52 ntpdate[5204]: step time server 130.126.24.24 offset -0.220645 sec

    When the configuration is committed, verify the clock settings:


    user@host> show system uptime
    Current time: 2007-11-01 17:57:09 PDT
System booted: 2007-11-01 14:36:38 PDT (03:20:31 ago)
Protocols started: 2007-11-01 14:37:30 PDT (03:19:39 ago)
Last configured: 2007-11-01 17:52:32 PDT (00:04:37 ago) by root
5:57PM up 3:21, 4 users, load averages: 0.00, 0.00, 0.00
  4. Set the Domain Name System (DNS) configuration.

    Many CAs use hostnames ( for example, FQDN) to specify various elements of the PKI. Since the CDP is usually specified using a URL containing an FQDN, you must configure a DNS resolver on the Junos device.

    [edit]user@host# set system name-server 4.2.2.1user@host# set system name-server 4.2.2.2user@host# commit and-quitcommit completeExiting configuration mode
  5. Generate the certificate request by:
    • Create a CA profile to specify the CA settings.
    • Generate the PKCS10 certificate request.

      The PKCS10 certificate request process involves generating a public/private key pair and then generating the certificate request itself, using the key pair.

      Note: Note the following information about the CA profile:

      • The CA profile defines the attributes of a certificate authority.
      • Each CA profile is associated with a CA certificate. If a new or renewed CA certificate should be loaded without removing the older CA certificate, a new profile must be created. This profile can also be used for online fetching of the CRL.
      • There can be multiple such profiles present in the system created for different users.
    1. Create a trusted CA profile with the following mandatory values:
      • CA profile name — (ms-ca for this example) (any value)
      • CA identity— labdomain.com. (CA domain name)
        user@host# set security pki ca-profile ms-ca ca-identity labdomain.com
    2. Create a revocation check to specify a method for checking certificate revocation:
      user@host# set security pki ca-profile ms-ca revocation-check crl

      Note: You can use the option disable to disable the revocation check or select crl to configure the CRL attributes.

    3. Set the refresh interval, in hours, to specify the frequency to update the CRL. The default values are: next-update time in CRL, or 1 week if no next-update time is specified.
      user@host# set security pki ca-profile ms-ca revocation-check crl refresh-interval 48
    4. Specify the location (URL) to retrieve CRL (HTTP or LDAP). By default, the URL is empty and uses CDP information embedded in the CA certificate.
      user@host# set security pki ca-profile ms-ca revocation-check crl url http://labsrv1.labdomain.com/CertEnroll/LABDOMAIN.crl

      Note: The URL can include the server-name/port information such as, ldap://<ip-or-fqdn>:<port>). If the port number is missing, HTTP will use port 80, or LDAP will use port 443. Currently you can configure only one URL. Support for backup URL configuration is not available.

    5. Specify an e-mail address to send the certificate request directly to a CA administrator.
      user@host# set security pki ca-profile ms-ca administrator email-address certadmin@labdomain.com

      Note: If you specify a CA administrator e-mail address to send the certificate request to, then the system composes an e-mail from the certificate request file and forwards it to the specified e-mail address. The e-mail status notification is sent to the administrator.

      Note: The certificate request can be sent to the CA through an out-of-band method.

    6. Commit the configuration:
      user@host# commit and-quitcommit completeExiting configuration mode
    7. Generate a key-pair request.

      When the CA profile is configured, the next step is to generate a key pair on the Junos device. To generate the private and public key pair:


      user@host> request security pki generate-key-pair certificate-id ms-cert size 1024
      Generated key pair ms-cert, key size 1024 bits

      The PKCS10 certificate request is generated and stored on the system as a pending certificate or certificate request. An e-mail notification will be sent to the administrator of the CA (in this example, certadmin@labdomain.com).

      Note: Currently the Junos OS supports only the RSA algorithm and does not support the Digital Signature Algorithm (DSA). A unique identity called certificate-ID is used to name the generated key pair. This ID is also used in certificate enrollment and request commands to get the right key pair. The generated key pair is saved in the certificate store in a file with the same name as the certificate-ID. The file size can be 512, 1024, or 2048 bits.

      A default (fallback) profile can be created if intermediate CAs are not preinstalled in the device. The default profile values are used in the absence of a specifically configured CA profile.

      In the case of a CDP, the following order is followed:

      • Per CA profile
      • CDP embedded in CA certificate
      • Default CA profile

      We recommend using a specific CA profiles instead of a default profile.

  6. Generate a local digital certificate request in the PKCS-10 format.

    user@host> request security pki generate-certificate-request certificate-id ms-cert subject "CN=john doe,CN=1.1.1.2,OU=sales,O=Juniper Networks, L=Sunnyvale,ST=CA,C=US" email user@juniper.net filename ms-cert-req
    Generated certificate request
-----BEGIN CERTIFICATE REQUEST-----
MIIB3DCCAUUCAQAwbDERMA8GA1UEAxMIam9obiBkb2UxDjAMBgNVBAsTBXNhbGVz
MRkwFwYDVQQKExBKdW5pcGVyIE5ldHdvcmtzMRIwEAYDVQQHEwlTdW5ueXZhbGUx
CzAJBgNVBAgTAkNBMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEA5EG6sgG/CTFzX6KC/hz6Czal0BxakUxfGxF7UWYWHaWFFYLqo6vXNO8r
OS5Yak7rWANAsMob3E2X/1adlQIRi4QFTjkBqGI+MTEDGnqFsJBqrB6oyqGtdcSU
u0qUivMvgKQVCx8hpx99J3EBTurfWL1pCNlBmZggNogb6MbwES0CAwEAAaAwMC4G
CSqGSIb3DQEJDjEhMB8wHQYDVR0RBBYwFIESInVzZXJAanVuaXBlci5uZXQiMA0G
CSqGSIb3DQEBBQUAA4GBAI6GhBaCsXk6/1lE2e5AakFFDhY7oqzHhgd1yMjiSUMV
djmf9JbDz2gM2UKpI+yKgtUjyCK/lV2ui57hpZMvnhAW4AmgwkOJg6mpR5rsxdLr
4/HHSHuEGOF17RHO6x0YwJ+KE1rYDRWj3Dtz447ynaLxcDF7buwd4IrMcRJJI9ws
-----END CERTIFICATE REQUEST-----
Fingerprint:
47:b0:e1:4c:be:52:f7:90:c1:56:13:4e:35:52:d8:8a:50:06:e6:c8 (sha1)
a9:a1:cd:f3:0d:06:21:f5:31:b0:6b:a8:65:1b:a9:87 (md5)

    Note: In the above sample of the PKCS10 certificate, the request starts with and includes the “BEGIN CERTIFICATE REQUEST” line and ends with and includes the “END CERTIFICATE REQUEST” line. This portion can be copied and pasted to your CA for enrollment. Optionally, you can also offload the “ms-cert-req” file and send that to your CA.

    Generate the PKCS10 certificate request to be sent to the CA.

    user@host> request security pki generate-certificate-request certificate-id id-name subject subject-name (domain-name domain-name | ip-address device-ip | email email-id) filename filename

    The available options are:

    • certificate-id — Name of the local digital certificate and the public/private key pair. This ensures that the proper key pair is used for the certificate request and ultimately for the local certificate.

    • subject — Distinguished name format that contains the common name, department, company name, state, and country:

      • CN — Common name
      • OU — Department
      • O — Company name
      • L — Locality
      • ST — State
      • C — Country
      • CN — Phone
      • DC — Domain component

        Note: You are not required to enter all subject name components. Note also that you can enter multiple values of each type.

    • domain-name — FQDN. The FQDN provides the identity of the certificate owner for IKE negotiations and provides an alternative to the subject name.
    • filename (path | terminal) — (Optional) Location where the certificate request should be placed, or the login terminal.
    • ip-address — (Optional) IP address of the device.
    • email — (Optional) e-mail address of CA administrator.

      Note: You must use one of these: domain-name, ip-address, or e-mail address.

      This defines the IKE ID type and will need to be configured to the IKE gateway profile described later in this document.

    The generated certificate request is stored in a specified file location. A local copy of the certificate request is saved in the local certificate storage. If the administrator reissues this command, the certificate request is generated once again.

    The PKCS10 certificate request is stored in a specified file and location, from which you can download it and send it to the CA for enrollment. If you have not specified the file name or location, you can get PKCS10 certificate request details by using the show security pki certificate-request certificate-id <id-name> command in the CLI. You can copy the command output and paste it into a Web front-end for the CA server or into an e-mail.

  7. Submit the certificate request to the CA, and retrieve the certificate.

    The administrator submits the certificate request to the CA. The CA administrator verifies the certificate request and generates a new certificate for the Junos device. The Junos device administrator retrieves it, along with the CA certificate and CRL.

    The process of retrieving the CA certificate, the device’s new local certificate, and CRL from the CA depends on the CA configuration and software vendor in use.

    For more information on how retrieve the certificates, see Appendix B: Administering Common Certificate Authorities.

    Junos OS supports the following CA vendors:

    • Entrust
    • Verisign
    • Microsoft

    Note: Although other CA software services such as OpenSSL can be used to generate certificates, these certificates are not verified by Junos OS.

    Junos OS may extend support to other vendors that conform to X.509 certificate standards.

  8. Load the local certificate, CA certificate, and CRL.

    The retrieved certificates (local certificate, CA certificate and CRL) should be loaded into the Junos device through FTP using the CLI.

    Assume the following names for certificates:

    • local certificate — certnew.cer
    • CA certificate — CA-certnew.cer
    • CRL — certcrl.crl
    user@host> file copy ftp://10.10.10.10/certnew.cer certnew.cer /var/tmp//...transferring.file.........crYdEC/100% of 1459 B 5864 kBpsuser@host> file copy ftp:// 10.10.10.10/CA-certnew.cer CA-certnew.cer /var/tmp//...transferring.file.........UKXUWu/100% of 1049 B 3607 kBpsuser@host> file copy ftp:// 10.10.10.10/certcrl.crl certcrl.crl /var/tmp//...transferring.file.........wpqnpA/100% of 401 B 1611 kBps

    Note: You can verify that all files have been uploaded by using the command file list.

  9. Load the certificate into local storage from the specified external file.

    You must also specify the certificate-ID in order to keep the proper linkage with the private/public key pair. This step loads the certificate into the RAM cache storage of the PKI module, checks the associated private key, and verifies the signing operation.


    user@host> request security pki local-certificate load certificate-id ms-cert filename certnew.cer
    Local certificate loaded successfully
  10. Load the CA certificate from the specified external file.

    You must specify the CA profile to associate the CA certificate to the configured profile.


    user@host> request security pki ca-certificate load ca-profile ms-ca filename CA-certnew.cer
    Fingerprint:
1b:02:cc:cb:0f:d3:14:39:51:aa:0f:ff:52:d3:38:94:b7:11:86:30 (sha1)
90:60:53:c0:74:99:f5:da:53:d0:a0:f3:b0:23:ca:a3 (md5)
Do you want to load this CA certificate ? [yes,no] (no) yes
CA certificate for profile ms-ca loaded successfully
  11. Load the CRL into the local storage.

    The allowed maximum size of the CRL is 5 MB. You must specify the associated CA profile in the command.


    user@host> request security pki crl load ca-profile ms-ca filename certcrl.crl
    CRL for CA profile ms-ca loaded successfully
  12. Verify that all certificates are loaded.

    You can display the details of all local certificates in the CLI interface.


    user@host> show security pki local-certificate certificate-id ms-cert detail Certificate
    identifier: ms-cert
Certificate version: 3
Serial number: 3a01c5a0000000000011
Issuer:
Organization: JuniperNetworks, Organizational unit: JTAC, Country: US, State:
CA, Locality: Sunnyvale,
Common name: TACLAB
Subject:
Organization: Juniper Networks, Organizational unit: sales, Country: US,
State: CA, Locality: Sunnyvale,
Common name: john doe
Alternate subject: "user@juniper.net", fqdn empty, ip empty
Validity:
Not before: 11- 2-2007 22:54
Not after: 11- 2-2008 23:04
Public key algorithm: rsaEncryption(1024 bits)
30:81:89:02:81:81:00:e4:41:ba:b2:01:bf:09:31:73:5f:a2:82:fe
1c:fa:0b:36:a5:d0:1c:5a:91:4c:5f:1b:11:7b:51:66:16:1d:a5:85
15:82:ea:a3:ab:d7:34:ef:2b:39:2e:58:6a:4e:eb:58:03:40:b0:ca
1b:dc:4d:97:ff:56:9d:95:02:11:8b:84:05:4e:39:01:a8:62:3e:31
31:03:1a:7a:85:b0:90:6a:ac:1e:a8:ca:a1:ad:75:c4:94:bb:4a:94
8a:f3:2f:80:a4:15:0b:1f:21:a7:1f:7d:27:71:01:4e:ea:df:58:bd
69:08:d9:41:99:98:20:36:88:1b:e8:c6:f0:11:2d:02:03:01:00:01
Signature algorithm: sha1WithRSAEncryption
Distribution CRL:
ldap:///CN=TACLAB,CN=TACLABSRV1,CN=CDP,CN=Public%20Key%20Services,CN=Services,
CN=Configuration,DC=tacdomain,DC=com?certificateRevocationList?base?
objectclass=cRLDistributionPoint
http://taclabsrv1.tacdomain.com/CertEnroll/TACLAB.crl
Fingerprint:
c9:6d:3d:3e:c9:3f:57:3c:92:e0:c4:31:fc:1c:93:61:b4:b1:2d:58 (sha1)
50:5d:16:89:c9:d3:ab:5a:f2:04:8b:94:5d:5f:65:bd (md5)

    Note: You can display the individual certificate details by specifying certificate-ID in the command line. Also, you can select the output format as either brief or detail.

  13. View the CA certificates.

    Display all CA certificates or the CA certificates of an individual CA profile (specified).


    user@host> show security pki ca-certificate ca-profile ms-ca detail
    Certificate identifier: ms-ca
Certificate version: 3
Serial number: 44b033d1e5e158b44597d143bbfa8a13
Issuer:
Organization: JuniperNetworks, Organizational unit: JTAC, Country: US, State:
CA, Locality: Sunnyvale,
Common name: TACLAB
Subject:
Organization: JuniperNetworks, Organizational unit: JTAC, Country: US, State:
CA, Locality: Sunnyvale,
Common name: TACLAB
Validity:
Not before: 09-25-2007 20:32
Not after: 09-25-2012 20:41
Public key algorithm: rsaEncryption(1024 bits)
30:81:89:02:81:81:00:d1:9e:6f:f4:49:c8:13:74:c3:0b:49:a0:56
11:90:df:3c:af:56:29:58:94:40:74:2b:f8:3c:61:09:4e:1a:33:d0
8d:53:34:a4:ec:5b:e6:81:f5:a5:1d:69:cd:ea:32:1e:b3:f7:41:8e
7b:ab:9c:ee:19:9f:d2:46:42:b4:87:27:49:85:45:d9:72:f4:ae:72
27:b7:b3:be:f2:a7:4c:af:7a:8d:3e:f7:5b:35:cf:72:a5:e7:96:8e
30:e1:ba:03:4e:a2:1a:f2:1f:8c:ec:e0:14:77:4e:6a:e1:3b:d9:03
ad:de:db:55:6f:b8:6a:0e:36:81:e3:e9:3b:e5:c9:02:03:01:00:01
Signature algorithm: sha1WithRSAEncryption
Distribution CRL:
ldap:///CN=TACLAB,CN=TACLABSRV1,CN=CDP,CN=Public%20Key%20Services,CN=Services,
CN=Configuration,DC=tacdomain,DC=com?certificateRevocationList?base?
objectclass=cRLDistributionPoint
http://taclabsrv1.tacdomain.com/CertEnroll/TACLAB.crl
Use for key: CRL signing, Certificate signing, Non repudiation
Fingerprint:
1b:02:cc:cb:0f:d3:14:39:51:aa:0f:ff:52:d3:38:94:b7:11:86:30 (sha1)
90:60:53:c0:74:99:f5:da:53:d0:a0:f3:b0:23:ca:a3 (md5)
  14. View the CRL.

    Display all loaded CRLs or the CRLs of the specified individual ca-profile.

    Note: You can select the output format as brief or detail to display CRL information; at present both options provide the same output.

    Syntax (operational mode):user@host> show security pki crl ca-profile ca-profile [brief | detail]Example:

    user@host> show security pki crl ca-profile ms-ca detail
    CA profile: ms-ca
CRL version: V00000001
CRL issuer: emailAddress = certadmin@juniper.net, C = US, ST = CA,
L = Sunnyvale, O = JuniperNetworks, OU = JTAC, CN = TACLAB
Effective date: 10-30-2007 20:32
Next update: 11- 7-2007 08:52
  15. Verify the certificate path for the local certificate and CA certificate.

    user@host> request security pki local-certificate verify certificate-id ms-cert
    Local certificate ms-cert verification success

    user@host> request security pki ca-certificate verify ca-profile ms-ca
    CA certificate ms-ca verified successfully
  16. Use the certificates in an IPsec VPN.

    Note: The steps for configuring a VPN using a certificate are similar to the steps for configuring a VPN using preshared keys. The only difference is the authentication method used for the IKE (Phase 1) policy. No changes are required for the IPsec (Phase 2) configuration because the use of certificates is part of Phase 1 negotiations.

    The following configuration steps describe how to configure a policy-based VPN as this method is most commonly used for dial-up VPNs.

    Note: For more information on VPN configuration, see the Junos Enhanced Services Configuration Guides.

    Note: For more information on Junos Enhanced Services Application Notes, see KB10182 (http://kb.juniper.net/KB10182) available at Juniper Networks Knowledge Base.

    To configure the IPsec VPN with the certificate:

    Note: Refer to the network diagram shown in Figure 1 to complete the following steps.

    1. Configure the security zones, and bind the interfaces to the appropriate zones. Make sure that all necessary host-inbound services are enabled on the interfaces or zones. In this example, enable Internet IKE service either on the ge-0/0/3 interface or on the untrust zone.
    2. Configure address book entries for each zone for the tunnel policies.
    3. Configure the IKE (Phase 1) proposals to use RSA encryption.
    4. Configure an IKE policy specifying the RSA proposal (from step above 3), local certificate, CA certificate, and x.509 type peer certificate.
    5. Configure the IKE gateway settings specifying the IKE policy (from step above 4), and a dynamic peer identified by the hostname.

      This step depends on how the certificate request was generated earlier. In this example, “CN=ssg5.juniper.net” was specified during the certificate request by the SSG5, which means that the IKE ID type is hostname.

    6. Configure the IPsec (Phase 2) VPN settings.

      Optionally you can also configure VPN monitor settings if required. In this example the Standard proposal set and PFS group 2 are used; however, you can create a different proposal if necessary.

    7. Configure tunnel policies to permit remote office traffic into the host LAN and vice versa. Also configure an outgoing “trust” to “untrust” permit-all policy with source NAT for Internet traffic. Be sure that the tunnel policy is above the permit-all policy. Otherwise the policy lookup will never reach the tunnel policy.
    8. Configure tcp-mss for IPsec traffic to eliminate the possibility of fragmented TCP traffic. This step reduces the resource usage on the device.
  17. Configure security zones and assign interfaces to the zones.

    The ingress (incoming) and egress (outgoing) zones are determined by the ingress and egress interfaces involved in the route lookup.

    In this example packets are incoming on ge-0/0/0, and the ingress zone is the trust zone.

    Following the route lookup, the egress interface is ge-0/0/3, and the egress zone is untrust zone. So the tunnel policy should be configured as “from-zone trust to-zone untrust” and vice versa.

    [edit]user@host# set security zones security-zone trust interfaces ge-0/0/0.0user@host# set security zones security-zone untrust interfaces ge-0/0/3.0
  18. Configure host-inbound services for each zone.

    Host-inbound services are for traffic destined for the Junos device. These settings includes but are not limited to the FTP, HTTP, HTTPS, IKE, ping, rlogin, RSH, SNMP, SSH, Telnet, TFTP, and traceroute.

    In this example we are assuming that all host-inbound services should be allowed from zone trust. For security reasons, we are allowing IKE only on the Internet-facing zone untrust which is required for IKE negotiations to occur. However, other services, such as services for management or troubleshooting can also be individually enabled if required.

    [edit]user@host# set security zones security-zone trust host-inbound-traffic system-services alluser@host# set security zones security-zone untrust host-inbound-traffic system-services ike
  19. Configure the address book entries for each zone.

    In this example we are using addressbook object names local-net and remote-net. There are some limitations with regard to which characters are supported for addressbook names. Please refer to the complete Junos OS documentation for more details.

    [edit]user@host# set security zones security-zone trust address-book address local-net 10.10.10.0/24user@host# set security zones security-zone untrust address-book address remote-net 192.168.168.0/24
  20. Configure the IKE (Phase 1) proposal to use RSA encryption.

    This example uses 3DES encryption, the SHA1 authentication algorithm, and Diffie-Hellman Group 2 keys.

    user@host# set security ike proposal rsa-prop1 authentication-method rsa-signaturesuser@host# set security ike proposal rsa-prop1 encryption-algorithm 3des-cbcuser@host# set security ike proposal rsa-prop1 authentication-algorithm sha1user@host# set security ike proposal rsa-prop1 dh-group group2
  21. Configure an IKE policy.

    Main mode is typically used for site-to-site VPNs with static IP peers whereas aggressive mode is used for dynamic IP and dial-up peers.

    Tthis example uses main modebecause both sides have static IPs even though the hostname (typically used for dynamic tunnels) is used here for the IKE ID.

    [edit]user@host# set security ike policy ike-policy1 mode mainuser@host# set security ike policy ike-policy1 proposals rsa-prop1user@host# set security ike policy ike-policy1 certificate local-certificate ms-certuser@host# set security ike policy ike-policy1 certificate peer-certificate-type x509- signatureuser@host# set security ike policy ike-policy1 certificate trusted-ca use-all
  22. Configure an IKE gateway.

    A remote IKE peer can be identified by IP address, FQDN/U-FQDN, or ASN1-DN (PKI certificates).

    In this example, we are identifying the peer by FQDN (hostname). Therefore the gateway IKE ID should be the remote peer’s domain name. You must specify the correct external interface or peer ID to properly identify the IKE gateway during Phase 1 setup.

    [edit]user@host# set security ike gateway ike-gate external-interface ge-0/0/3.0user@host# set security ike gateway ike-gate ike-policy ike-policy1user@host# set security ike gateway ike-gate dynamic hostname ssg5.juniper.net
  23. Configure the IPsec policy.

    In this example, we are using the Standard proposal set, which includes esp-group2-3des-sha1 and esp-group2- aes128-sha1 proposals. However, a unique proposal may be created and then specified in the IPsec policy if needed.

    [edit]user@host# set security ipsec policy vpn-policy1 proposal-set standard[edit]user@host# set security ipsec policy vpn-policy1 perfect-forward-secrecy keys group2
  24. Configure the IPsec VPN with an IKE gateway and IPsec policy.

    In this example, the VPN name ike-vpn must be referenced in the tunnel policy to create a security association. Additionally, if required, an idle time and a proxy ID can be specified if they are different from the tunnel policy addresses.

    [edit]user@host# set security ipsec vpn ike-vpn ike gateway ike-gateuser@host# set security ipsec vpn ike-vpn ike ipsec-policy vpn-policy1
  25. Configure bidirectional tunnel policies for VPN traffic.

    In this example, traffic from the host LAN to the remote office LAN requires a “from-zone trust to-zone untrust” tunnel policy. However if a session needs to originate from the remote LAN to the host LAN, then a tunnel policy in the opposite direction “from-zone untrust to-zone trust” is also required. By specifying the policy in the opposite direction as the pair-policy, the VPN becomes bidirectional. Note also that in addition to action permit, we also need to specify the IPsec profile to be used. Furthermore source NAT can be enabled on the policy if desired, but that is beyond the scope of this application note. Note that for tunnel policies, the action is always permit. In fact if you are configuring a policy with action of deny, you will not see an option for specifying the tunnel.

    [edit security policies from-zone trust to-zone untrust]user@host# edit security policies from-zone trust to-zone untrustuser@host# set policy tunnel-policy-out match source-address local-netuser@host# set policy tunnel-policy-out match destination-address remote-netuser@host# set policy tunnel-policy-out match application anyuser@host# set policy tunnel-policy-out then permit tunnel ipsec-vpn ike-vpn pair-policy tunnel-policy-inuser@host# top edit security policies from-zone untrust to-zone trustuser@host# set policy tunnel-policy-in match source-address remote-netuser@host# set policy tunnel-policy-in match destination-address local-netuser@host# set policy tunnel-policy-in match application anyuser@host# set policy tunnel-policy-in then permit tunnel ipsec-vpn ike-vpn pair-policy tunnel-policy-out[edit security policies from-zone untrust to-zone trust]user@host# topuser@host# exit
  26. Configure a security policy for Internet traffic.

    A security policy is required to permit all traffic from zone trust to zone untrust.

    The device uses the specified source-nat interface, and translates the source IP address and port for outgoing traffic, using the IP address of the egress interface as the source IP address and a random higher port for the source port. If required, more granular policies can be created to permit/deny certain traffic.

    [edit]user@host# edit security policies from-zone trust to-zone untrust[edit security policies from-zone trust to-zone untrust]user@host# set policy any-permit match source-address anyuser@host# set policy any-permit match destination-address anyuser@host# set policy any-permit match application anyuser@host# set policy any-permit then permit source-nat interfaceuser@host# topuser@host# exit
  27. Note that the security policy should be below the tunnel policy in the hierarchy because the policy list is read from top to bottom. If this policy were above the tunnel policy, then the traffic would always matche this policy and would not continue to the next policy. Thus no user traffic would be encrypted. To move the tunnel policy above the any-permit policy, use the insert policy command as shown below:
    [edit]user@host# edit security policies from-zone trust to-zone untrust[edit security policies from-zone trust to-zone untrust]user@host# insert policy tunnel-policy-out before policy any-permituser@host# topuser@host# exit
  28. Configure the tcp-mss (TCP maximum segment size) setting for TCP traffic across the tunnel.

    TCP-MSS is negotiated as part of the TCP 3-way handshake. It limits the maximum size of a TCP segment to accommodate the maximum transmission unit (MTU) limits on a network. This is very important for VPN traffic as the IPsec encapsulation overhead along with the IP and frame overhead can cause the resulting ESP packet to exceed the MTU of the physical interface, causing fragmentation. Fragmentation increases the bandwidth and device resources usage, and it should always be best avoided.

    The recommended value to use for tcp-mss is 1350 for most Ethernet-based networks with an MTU of 1500 or higher. This value may need to be altered if any device in the path has a lower value of MTU or if there is any added overhead such as PPP, Frame Relay, and so on. As a general rule, you may need to experiment with different tcp-mss values to obtain optimal performance.

    user@host# set security flow tcp-mss ipsec-vpn mss mss-valueExample:[edit]user@host# set security flow tcp-mss ipsec-vpn mss 1350[edit]user@host# commit and-quitcommit completeExiting configuration mode
  29. This step provides information on SSG device configuration. Because the focus of this example is on Junos OS configuration and troubleshooting, the SSG device configuration is explained briefly in this step.

    To show the configuration settings in Figure 1, a sample of the relevant configurations is provided from an SSG5 device strictly for reference.

    However, the concepts with regard to configuration of policy-based VPNs for Juniper Networks Firewall/VPN products are available in the Concepts and Examples (C&E) guides. For more information, see the Concepts & Examples ScreenOS Reference Guide available at http://www.juniper.net/techpubs/software/screenos/.

    The following example is a relevant sample of an SSG5 configuration:

    user@host# set interface ethernet0/6 ip 192.168.168.1/24user@host# set interface ethernet0/6 routeuser@host# set interface ethernet0/0 ip 2.2.2.2/30user@host# set interface ethernet0/0 routeuser@host# set flow tcp-mss 1350user@host# set domain juniper.netuser@host# set hostname ssg5user@host# set pki x509 default cert-path partialuser@host# set pki x509 dn country-name "US"user@host# set pki x509 dn state-name "CA"user@host# set pki x509 dn local-name "Sunnyvale"user@host# set pki x509 dn org-name "Juniper Networks"user@host# set pki x509 dn org-unit-name "Sales"user@host# set pki x509 dn ip 2.2.2.2user@host# set dns host dns1 4.2.2.1user@host# set dns host dns2 4.2.2.2user@host# set address "Trust" "local-net" 192.168.168.0 255.255.255.0user@host# set address "Untrust" "corp-net" 10.10.10.0 255.255.255.0user@host# set ike gateway "corp-ike" address 1.1.1.2 Main outgoing-interface ethernet0/0 proposal "rsa-g2- 3des-sha"user@host# set vpn "corp-vpn" gateway "corp-ike" replay tunnel idletime 0 sec-level standarduser@host# set policy id 11 from "Trust" to "Untrust" "local-net" "corp-net" "ANY" tunnel vpn "corp-vpn" pairpolicy 10user@host# set policy id 10 from "Untrust" to "Trust" "corp-net" "local-net" "ANY" tunnel vpn "corp-vpn" pairpolicy 11user@host# set policy id 1 from "Trust" to "Untrust" "ANY" "ANY" "ANY" nat src permituser@host# set ntp server "130.126.24.24"user@host# set route 0.0.0.0/0 interface ethernet0/0 gateway 2.2.2.1

Verification

Verification and troubleshooting of the IKE and IPsec are similar to that site-to-site VPNs using preshared keys except for the use of the certificate for IKE identification, authentication, and encryption methods.

For more information, see the following:

Use the following steps to verify the IKE and IPsec configuration:

Confirm IKE Phase 1 Status

Purpose

To confirm the VPN status by checking any IKE Phase 1 security associations status.

PKI related to IPsec tunnels is formed during Phase 1 setup. Completion of Phase 1 indicates that PKI was successful.

Action


user@host> show security ike security-associations

Index Remote Address State Initiator cookie Responder cookie Mode
 202.2.2.2 UP af4f78bc135e4365 48a35f853ee95d21 Main

Meaning

The output indicates that

Incorrect output would indicate that:

Get Details on Individual Security Associations

Purpose

Get details on individual IKE security associations (SAs).

Action


user@host> show security ike security-associations index 20 detail
IKE peer 2.2.2.2, Index 20,
Role: Responder, State: UP
Initiator cookie: af4f78bc135e4365, Responder cookie: 48a35f853ee95d21
Exchange type: Main, Authentication method: RSA-signatures
Local: 1.1.1.2:500, Remote: 2.2.2.2:500
Lifetime: Expires in 23282 seconds
Algorithms:
Authentication : sha1
Encryption : 3des-cbc
Pseudo random function: hmac-sha1
Traffic statistics:
Input bytes : 10249
Output bytes : 4249
Input packets: 10
Output packets: 9
Flags: Caller notification sent
IPsec security associations: 2 created, 1 deleted
Phase 2 negotiations in progress: 0

Meaning

The output displays the details of the individual IKE SAs such as role (initiator or responder), status, exchange type, authentication method, encryption algorithms, traffic statistics, Phase 2 negotiation status, and so on.

You can use the output data to:

Confirming IPsec Phase 2 Status

Purpose

View IPsec (Phase 2) security associations.

Phase 2 happens same was as it does with non-certificate-based VPNs.

When IKE Phase 1 is confirmed, view the IPsec (Phase 2) security associations.

Action


user@host> show security ipsec security-associations
total configured sa: 2
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<2 2.2.2.2 500 ESP:3des/sha1 bce1c6e0 1676/ unlim - 0
>2 2.2.2.2 500 ESP:3des/sha1 1a24eab9 1676/ unlim - 0

Meaning

The output indicates that

Note: Phase 2 lifetime can be different from the Phase 1 lifetimebecause Phase 2 is not dependent on Phase 1 after the VPN is up.

Note: For information on VPN monitoring, refer to the complete documentation for Junos OS available at http://www.juniper.net/techpubs/.

Display IPsec Security Association Details

Purpose

Display the individual IPsec SA details identified by the index number.

Action


user@host> show security ipsec security-associations index 2 detail
Virtual-system: Root
Local Gateway: 1.1.1.2, Remote Gateway: 2.2.2.2
Local Identity: ipv4_subnet(any:0,[0..7]=10.10.10.0/24)
Remote Identity: ipv4_subnet(any:0,[0..7]=192.168.168.0/24)
DF-bit: clear
Policy-name: tunnel-policy-out
Direction: inbound, SPI: bce1c6e0, AUX-SPI: 0
Hard lifetime: Expires in 1667 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1093 seconds
Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: -
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
Anti-replay service: enabled, Replay window size: 32
Direction: outbound, SPI: 1a24eab9, AUX-SPI: 0
Hard lifetime: Expires in 1667 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1093 seconds
Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: -
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
Anti-replay service: enabled, Replay window size: 32

Meaning

The output displays the local Identity and the remote Identity.

Note that a proxy ID mismatch may cause Phase 2 completion to fail. The proxy ID is derived from the tunnel policy (for policy-based VPNs). The local address and remote address are derived from the address book entries, and the service is derived from the application configured for the policy.

If Phase 2 fails due to a proxy ID mismatch, verify which address book entries are configured in the policy and ensure that the correct addresses are sent. Also ensure that the ports are matching. Double-check the service to ensure that the ports match for the remote and local servers.

Note: If multiple objects are configured in a tunnel policy for source address, destination address, or application then the resulting proxy ID for that parameter is changed to zeroes.

For example, assume the following scenario for a tunnel policy:

  • Local addresses of 10.10.10.0/24 and 10.10.20.0/24
  • Remote address of 192.168.168.0/24
  • Application as junos-http

The resulting proxy ID is local 0.0.0.0/0, remote 192.168.168.0/24, service 80.

The resulting proxy IDs can affect the interoperability if the remote peer is not configured for the second subnet. Also if you are employing a third-party vendor’s application, you may have to manually enter the proxy ID to match.

If IPsec fails to complete, then check the kmd log or set traceoptions. For more information, see Troubleshooting IKE, PKI, and IPsec Issues.

Check IPsec SA Statistics

Purpose

Check statistics and errors for an IPsec SA.

For troubleshooting purpose, check the Encapsulating Security Payload/Authentication Header (ESP/AH) counters for any errors with a particular IPsec SA.

Action


user@host> show security ipsec statistics index 2
ESP Statistics:
Encrypted bytes: 674784
Decrypted bytes: 309276
Encrypted packets: 7029
Decrypted packets: 7029
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0

Meaning

An error value of zero in the output indicates a normal condition.

We recommend running this command multiple times to observe any packet loss issues across a VPN. Output from this command also displays the statistics for encrypted and decrypted packet counters, error counters, and so on.

You must enable security flow traceoptions to investigate which ESP packets are experiencing errors and why. For more information, see Troubleshooting IKE, PKI, and IPsec Issues.

Test Traffic Flow Across the VPN

Purpose

Test traffic flow across the VPN after Phase 1 and Phase 2 have completed successfully. You can test traffic flow by using the ping command. You can ping from local host to remote host. You can also initiate pings from the Junos device itself.

This example shows how to initiate a ping request from the Junos device to the remote host. Note that when pings are initiated from the Junos device, the source interface must be specified to ensure that the correct route lookup takes place and the appropriate zones are referenced in the policy lookup.

In this example, the ge-0/0/0.0 interface resides in the same security zone as the local host and must be specified in the ping request so that the policy lookup can be from zone trust to zone untrust.

Action


user@host> ping 192.168.168.10 interface ge-0/0/0 count 5
PING 192.168.168.10 (192.168.168.10): 56 data bytes
64 bytes from 192.168.168.10: icmp_seq=0 ttl=127 time=8.287 ms
64 bytes from 192.168.168.10: icmp_seq=1 ttl=127 time=4.119 ms
64 bytes from 192.168.168.10: icmp_seq=2 ttl=127 time=5.399 ms
64 bytes from 192.168.168.10: icmp_seq=3 ttl=127 time=4.361 ms
64 bytes from 192.168.168.10: icmp_seq=4 ttl=127 time=5.137 ms
--- 192.168.168.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.119/5.461/8.287/1.490 ms

Confirm the Connectivity

Purpose

Confirm the connectivity between a remote host and a local host.

Action


ssg5-> ping 10.10.10.10 from ethernet0/6
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 1 seconds from ethernet0/6
!!!!!
Success Rate is 100 percent (5/5), round-trip time min/avg/max=4/4/5 ms

Meaning

You can confirm end-to-end connectivity by using the ping command from the remote host to the local host. In this example, the command is initiated from the SSG5 device.

Failed end-to-end connectivity may indicate an issue with routing, policy, end host, or encryption/decryption of the ESP packets. To verify the exact causes of the failure:

Troubleshooting IKE, PKI, and IPsec Issues

The basic troubleshooting steps are as follows:

  1. Identifying and isolating the problem.
  2. Debugging the problem.

The common approach of starting troubleshooting is with the lowest layer of the OSI layers and working your way up the OSI stack to confirm the layer in which the failure occurs. The steps for troubleshooting IKE, PKI, and IPsec are as follows:

Junos OS includes the traceoptions feature. Using this feature, you can enable a traceoption flag to write the data from the traceoption to a log file, which may be predetermined or manually configured and stored in flash memory. These trace logs can be retained even after a system reboot. Check the available flash storage before implementing traceoptions.

You can enable the traceoptions feature in configuration mode and commit the configuration to use the traceoptions feature. Similarly to disable traceoptions, you must deactivate traceoptions in configuration mode and commit the configuration.

Check the Free Disk Space on Your Device

Problem

Check the statistics on the free disk space in your device file systems.

Solution


user@host> show system storage
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1a 213M 74M 137M 35% /
devfs 1.0K 1.0K 0B 100% /dev
devfs 1.0K 1.0K 0B 100% /dev/
/dev/md0 180M 180M 0B 100% /junos
/cf 213M 74M 137M 35% /junos/cf
devfs 1.0K 1.0K 0B 100% /junos/dev/
procfs 4.0K 4.0K 0B 100% /proc
/dev/bo0s1e 24M 13K 24M 0% /config
/dev/md1 168M 7.6M 147M 5% /mfs
/cf/var/jail 213M 74M 137M 35% /jail/var

The /dev/ad0s1a represents the onboard flash memory and is currently at 35% capacity.

Note: You can view the available system storage in the J-Web interface under the System Storage option.

Note: You can enable traceoptions to log the trace data to the filenames specified or to the default log file to receive the output of the tracing operation.

The output of the traceoptions is placed in /var/log/kmd.

Check the Log Files to Verify Different Scenarios and Upload Log Files to an FTP

Problem

View the log files to check security IKE debug messages, security flow debugs, and the state of logging to the syslog.

Solution

user@host> show log kmduser@host> show log pkiduser@host> show log security-traceuser@host> show log messages

Note: You can view a list of all logs in the /var/log directory by using the show log command.

Log files can also be uploaded to an FTP server by using the file copy command.

(operational mode):user@host> file copy path/filename dest-path/filenameExample:

user@host> file copy /var/log/kmd ftp://10.10.10.10/kmd.log

ftp://10.10.10.10/kmd.log 100% of 35 kB 12 MBps

Enable IKE Traceoptions to View Messages on IKE

Problem

To view success or failure messages for IKE or IPsec, you can view the key management process (kmd) log by using the show log kmd command. Because the kmd log displays some general messages, it may be useful to obtain additional details by enabling IKE and PKI traceoptions.

Note: Generally, it is best practice to troubleshoot the peer which has the responder role. You must obtain the trace output from the initiator and responder to understand the cause of a failure.

Configure IKE tracing options.

Solution

user@host> configureEntering configuration mode[edit]user@host# edit security ike traceoptions[edit security ike traceoptions]

user@host# set file ?
Possible completions:
<filename> Name of file in which to write trace information
files Maximum number of trace files (2..1000)
match Regular expression for lines to be logged
no-world-readable Don't allow any user to read the log file
size Maximum trace file size (10240..1073741824)
world-readable Allow any user to read the log file
[edit security ike traceoptions]

user@host# set flag ?
Possible completions:
all Trace everything
certificates Trace certificate events
database Trace security associations database events
general Trace general events
ike Trace IKE module processing
parse Trace configuration processing
policy-manager Trace policy manager processing
routing-socket Trace routing socket messages
timer Trace internal timer events

Note: If you do not specify file names for the <filename> field, then all IKE traceoptions are written to the kmd log.

You must specify at least one flag option to write trace data to the log. For example:

Note: You must commit your configuration to start the trace.

Enable PKI Traceoptions to View Messages on IPsec

Problem

Enable PKI traceoptions to identify whether an IKE failure is related to the certificate or to a non-PKI issue.

Solution

user@host> configureEntering configuration mode[edit]user@host# edit security pki traceoptions[edit security pki traceoptions]

user@host# set file ?
Possible completions:
<filename> Name of file in which to write trace information
files Maximum number of trace files (2..1000)
match Regular expression for lines to be logged
no-world-readable Don't allow any user to read the log file
size Maximum trace file size (10240..1073741824)
world-readable Allow any user to read the log file
[edit security pki traceoptions]

user@host# set flag ?
Possible completions:
all Trace with all flags enabled
certificate-verification PKI certificate verification tracing
online-crl-check PKI online crl tracing

Setting up IKE and PKI Traceoptions to Troubleshoot IKE Setup Issues with Certificates

Problem

Configure the recommended settings for IKE and PKI traceoptions.

Note: The IKE and PKI traceoptions use the same parameters, but the default filename for all PKI-related traces is found in the pkid log.

Solution

user@host> configureEntering configuration mode[edit]user@host# edit security ike traceoptions[edit security ike traceoptions]user@host# set file size 1muser@host# set flag ikeuser@host# set flag policy-manageruser@host# set flag routing-socketuser@host# set flag certificates[edit security ike traceoptions]user@host# top edit security pki traceoptions[edit security pki traceoptions]user@host# set file size 1m[edit security pki traceoptions]user@host# set flag all[edit security pki traceoptions]user@host# commit and-quitcommit completeExiting configuration mode

Analyzing the Phase 1 Success Message

Problem

Understand the output of the show log kmd command where the IKE Phase 1 and Phase 2 conditions are successful.

Solution

Nov 7 11:52:14 Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=
1.1.1.2) remote=fqdn(udp:500,[0..15]=ssg5.juniper.net)
Nov 7 11:52:14 Phase-2 [responder] done for
p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=fqdn(udp:500,[0..15]=ssg5.juniper.net)
p2_local=ipv4_subnet(any:0,[0..7]=10.10.10.0/24)
p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)

The sample output indicates:

Analyzing the Phase 1 Failure Message (Proposal Mismatch)

Problem

Understand the output of the show log kmd command, where the IKE Phase 1 condition is a failure. This procedure helps in determining the reason for the VPN not establishing Phase 1.

Solution

Nov 7 11:52:14 Phase-1 [responder] failed with error(No proposal chosen) for
local=unknown(any:0,[0..0]=) remote=fqdn(udp:500,[0..15]=ssg5.juniper.net)
Nov 7 11:52:14 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 011359c9 ddef501d - 2216ed2a bfc50f5f [-
1] / 0x00000000 } IP; Error = No proposal chosen (14)

The sample output indicates that

To resolve this issue, ensure that the parameters for the IKE gateway Phase 1 proposals on both the responder and the initiator match. Also confirm that a tunnel policy exists for the VPN.

Analyzing the Phase 1 Failure Message (Authentication Failure)

Problem

Understand the output of the show log kmd command when the IKE Phase 1 condition is a failure. This helps in determining the reason for the VPN not establishing Phase 1.

Solution

Nov 7 12:06:36 Unable to find phase-1 policy as remote peer:2.2.2.2 is not recognized.
Nov 7 12:06:36 Phase-1 [responder] failed with error(Authentication failed) for
local=ipv4(udp:500,[0..3]=1.1.1.2) remote=ipv4(any:0,[0..3]=2.2.2.2)
Nov 7 12:06:36 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { f725ca38 dad47583 - dab1ba4c ae26674b [-
1] / 0x00000000 } IP; Error = Authentication failed (24)

The sample output indicates that

To resolve this issue, confirm that the correct peer IKE ID type is specified on the local peer based on the following:

Analyzing the Phase 1 Failure Message (Timeout Error)

Problem

Understand the output of the show log kmd command when the IKE Phase 1 condition is a failure.

Solution

Nov 7 13:52:39 Phase-1 [responder] failed with error(Timeout) for local=unknown(any:0,[0..0]=)
remote=ipv4(any:0,[0..3]=2.2.2.2)

The sample output indicates that:

Because this timeout error is the result of waiting on a response from the PKI daemon, you must review the PKI traceoptions output to see whether there is a problem with PKI.

Analyzing the Phase 2 Failure Message

Problem

Understand the output of the show log kmd command when the IKE Phase 2 condition is a failure.

Solution

Nov 7 11:52:14 Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=
1.1.1.2) remote=fqdn(udp:500,[0..15]=ssg5.juniper.net)
Nov 7 11:52:14 Failed to match the peer proxy ids
p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)
p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24) for the remote peer:ipv4(udp:500,[0..3]=2.2.2.2)
Nov 7 11:52:14 KMD_PM_P2_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-2 [responder] failed for
p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2)
p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24)
p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)
Nov 7 11:52:14 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 41f638eb cc22bbfe - 43fd0e85 b4f619d5 [0]
/ 0xc77fafcf } QM; Error = No proposal chosen (14)

The sample output indicates that

Analyzing the Phase 2 Failure Message

Problem

Understand the output of the show log kmd command when the IKE Phase 2 condition is a failure.

Solution

Nov 7 11:52:14 Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=
1.1.1.2) remote=fqdn(udp:500,[0..15]=ssg5.juniper.net)
Nov 7 11:52:14 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { cd9dff36 4888d398 - 6b0d3933 f0bc8e26 [0]
/ 0x1747248b } QM; Error = No proposal chosen (14)

The sample output indicates that:

Common Problems Related to IKE and PKI

Problem

Troubleshoot common problems related to IKE and PKI.

Enabling the traceoptions feature helps you to gather more information on the debugging issues than is obtainable from the normal log entries. You can use the traceoptions log to understand the reasons for IKE or PKI failures.

For detailed analysis on the IKE and PKI problems and traceoptions outputs, contact Juniper Networks JTAC Support or visit the Juniper Networks Support Website at http://www.juniper.net/support for further assistance.

Solution

Methods for troubleshooting the IKE -and-PKI-related issues:

Related Topics

Copyright© 1999-2010 Juniper Networks, Inc. All rights reserved.