Juniper Networking Technologies DAY ONE: ADVPN DESIGN AND IMPLEMENTATION Using the AutoDiscovery VPN protocol is a new and different approach to solving real-world IPsec encryption problems Get ahead of the curve and into the lab with this workbook full of overviews, configurations, and troubleshooting samples By Mark Barrett, Dale Shaw, and Scott McKinnon DAY ONE: ADVPN DESIGN AND IMPLEMENTATION Neither the fully-meshed nor hub-and-spoke approaches to IPsec VPNs are optimal for modern network deployments where customers demand both the ease of provisioning encrypted overlay security services and the optimum flow of traffic to minimize application traffic latency What is needed is an approach that takes the simplified provisioning of hub-and-spoke with the low application latency of fully-meshed Spokes should have the capability to temporary build tunnels between each other on an on-demand basis to create the most efficient forwarding path, so if a particular flow is required, the spokes build dynamic tunnels between themselves for that communication and then clear the tunnel when idle In this way the fully-meshed approach is available to the network without the overhead of configuring all the necessary communication paths The hub takes care of the task of identifying whether dynamic connections are required The SRX Series employs a feature called AutoVPN to deliver this capability, which has been shipping since Junos 12.1X44 Now AutoVPN deployments can use the Auto Discovery VPN (ADVPN) protocol to dynamically establish spoke-tospoke VPN tunnels This Day One book will tell you why and show you how, while providing sample implementations to investigate in your lab IT’S DAY ONE AND YOU HAVE A JOB TO DO, SO LEARN HOW TO: nn Gain an appreciation of the main issues surrounding the integration of encryption technology into networking products nn Understand the need for a standards-based approach to solving network integration issues nn Understand Juniper’s AutoDiscovery VPN (ADVPN) solution nn Learn how to incorporate the ADVPN feature into a design nn Explore the detailed steps required to implement and tune ADVPN in your network nn Take architectural blueprint designs as a base template to be tailored for your specific scenario Juniper Networks Books are singularly focused on network productivity and efficiency Peruse the complete library at www.juniper.net/books Published by Juniper Networks Books ISBN 978-1941441169 781941 441169 51800 Juniper Networking Technologies Day One: ADVPN Design and Implementation By Mark Barrett, Dale Shaw, and Scott McKinnon Chapter 1: Why ADVPN ? Chapter 2: A Standards-based Approach .15 Chapter 3: ADVPN Key Concepts 21 Chapter 4: Key Configuration Steps 27 Chapter 5: Tuning Considerations for ADVPN 35 Chapter 6: Management and Day-to-Day Operations 53 Chapter 7: Using Junos Automation to Help Manage ADVPN Environments 61 Chapter 8: Troubleshooting ADVPN 67 Chapter 9: Architectural Blueprints 79 Appendices 113 iv © 2015 by Juniper Networks, Inc All rights reserved Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc in the United States and other countries The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners Juniper Networks assumes no responsibility for any inaccuracies in this document Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice About the Authors Published by Juniper Networks Books Authors: Mark Barrett, Dale Shaw, and Scott McKinnon Technical Reviewers: Johan Andersson, Anubhav Garg, Bill Shelton Editor in Chief: Patrick Ames Copyeditor and Proofer: Nancy Koerbel Illustrator: Karen Joice J-Net Community Manager: Julie Wider To the rest of the author team, thank you for your persistence as we all have busy day jobs that often turned into our night jobs as well, to get the book completed To the engineering team (Praveen Sathyanarayan, Anubhav Gar, Suresh Melam and, Rajendra Kandukuri) putting up with field SEs pestering and challenging to go the extra mile for the first release of ADVPN through the alpha and beta phases To our review team (Bill Shelton, Gavin Thirlwall, Johan Andersson) for making sure what we wrote would be useful to people in the field To our editing support team, Nancy Koerbel sorry for the Australian English and Karen Joice thanks for turning our diagrams into something nice And finally Patrick Ames, giving us the confidence to start the project, keeping the relatively big author team on track, and cracking the whip when we all needed a push ISBN: 978-1-936779-16-9 (print) Printed in the USA by Vervante Corporation ISBN: 978-1-936779-17-6 (ebook) Version History: v1, September 2015 10 This book is available in a variety of formats at: http://www.juniper.net/dayone Mark Barrett Mark Barrett has been working in the networking industry for 28 years He has been through many networking technology transitions (both protocols and transmission techniques) from his part time University jobs, to IBM, Cisco, and the Australian Federal Police, to his current position as a Juniper Networks Systems Engineer No matter the technology, Mark has maintained a keen interest in high speed networking LAN and WAN technologies and, in particular, how they need to be secured v About the Authors (continued) Dale Shaw Dale Shaw is a Systems Engineer in the Australian Federal Government team at Juniper Networks He has worked for Juniper Networks in Canberra since the beginning of 2014, helping government enterprises to design, build and manage secure IP networks Prior to Juniper Networks, Dale spent seven years working for Alphawest and Optus Business as a solutions designer and architect In these roles Dale helped design, deploy and operate large scale IP networks carrying voice, video and data over IPsec VPNs Dale holds a number of industry certifications such as JNCIP-ENT, JNCIP-SEC, and CCIE R&S (#24464) I’d like to thank my co-authors, Mark Barrett and Scott McKinnon, for making this project happen Patrick Ames has been an excellent “cat herder” and Nancy Koerbel a cold and clinical assassin of all of the British English we handed over (just kidding, Nancy, you applied a generous quantity of polish!) Praveen Sathyanarayan is not only the chief designer of ADVPN itself but also provided a lot of invaluable technical information and review along the way thanks Praveen! Thanks also to Bill Shelton and Gavin Thirlwall, from the Juniper US federal and UK government teams, respectively, for providing inputs specific to their geographic contexts, and to Johan Andersson and Anubhav Garg for their inputs and reviews Last but certainly not least, I would like to thank my wife, Katie, and my two kids, for tolerating all of my nerdy (often late night) pursuits Scott McKinnon Scott McKinnon is a Senior Product Manager in the Juniper Networks Security and Switching Product Team (SSPT) within the Juniper Design and Innovation (JDI) group Scott has been working with IPsec and related encryption technologies for over 15 years, and has experience in post-sales and pre-sales, as well as product management He has contributed to the development of the ADVPN capability and related technologies, like GDoI, from initial customer requirements through product specification and into customer trials and release He holds an MBA in Technology Management from the Open University (UK), as well as a BEng(Hons) in Engineering from Glasgow Caledonian University(UK) Scott manages Juniper's public sector accreditation program, where many of the ADVPN requirements originated He is based in Sunnyvale, California Scott would like to acknowledge the contributions of John Veizades and Steve Hanna to the initial stages of what became ADVPN and to applaud the design and execution by the Juniper JDI Engineering Team of Suresh Melam, Praveen Sathyanarayan, Anubhav Garg, Vineeth Kisara, Rajendra Kandukuri, and Jinesh Doshi Thanks to the main authors, Mark and Dale, and to our reviewers Bill Shelton, Gavin Thirlwall, and Johan Andersson, and editors Patrick, Nancy, and Karen vi Welcome to Day One This book is part of a growing library of Day One books, produced and published by Juniper Networks Books Day One books were conceived to help you get just the information that you need on day one The series covers Junos OS and Juniper Networks networking essentials with straightforward explanations, step-by-step instructions, and practical examples that are easy to follow The Day One library also includes a slightly larger and longer suite of This Week books, whose concepts and test bed examples are more similar to a weeklong seminar You can obtain either series, in multiple formats: Download a free PDF edition at http://www.juniper.net/dayone Get the ebook edition for iPhones and iPads from the iTunes Store Search for Juniper Networks Books Get the ebook edition for any device that runs the Kindle app (Android, Kindle, iPad, PC, or Mac) by opening your device’s Kindle app and going to the Kindle Store Purchase the paper edition at either Vervante Corporation (www vervante.com) for between $12-$28, depending on page length Note that Nook, iPad, and various Android apps can also view PDF files What You Need to Know Before Reading This Book Before reading this book, you should be familiar with the basic administrative functions of the Junos operating system, including the ability to work with operational commands and to read, understand, and change Junos configurations There are several books in the Day One library on learning Junos, at www.juniper.net/dayone This book assumes that you, the reader, know: Basic IP networking design and operation Basic IPsec protocol implementation Basic Junos OS CLI procedures Basic SRX concepts and principles vii After Reading This Book, You’ll Be Able To Gain an appreciation of the main issues surrounding the integration of encryption technology into networking products Understand the need for a standards-based approach to solving network integration issues Understand Juniper’s AutoDiscovery VPN (ADVPN) solution Learn how to incorporate the ADVPN feature into a customer design Explore the detailed steps required to implement and tune ADVPN in the customer network Apply architectural blueprint designs as a base template to be tailored for your specific customer scenario Preface IP Security, or more simply IPsec, is the Internet Engineering Task Force (IETF’s) standard for securing the network layer in IP systems, covering both IPv4 and IPv6 IPsec was originally defined by the IETF in 1998 and since then has been defined as an optional element for IPv4 and a mandatory element for IPv6 IPsec has gone through a number of iterations over the years and many additional RFCs have been defined to augment the main elements of the protocol with new encryption algorithms, authentication functions, and modes of operation While IPsec has been around for awhile, implementing such a protection suite in IP networks remains a challenge Network devices such as routers and firewalls require the protocol to be integrated into their operating systems to assert security policy The security capabilities of IPsec must be deployed in network topologies that are evolving to support the demands of ever-newer applications and services, and the protocol must coexist with dynamic routing protocols in order to maintain efficient forwarding of traffic in the event of disruption These conflicting challenges have resulted in unfortunate compromises being made between ease-of-design, deployment, ongoing management, and securing the application traffic efficiently within a service oriented network model Until now viii Juniper Networks SRX Series of security gateway devices are a range of network products designed to integrate security, routing, and switching in a single Junos OS platform IPsec is therefore a cornerstone of any such platform Scope of Book This Day One book attempts to cover the following ADVPN concepts, and was written in such a way that you can follow along in your own lab: Configuration Tuning Service Management Blueprints Automation Futures Chapter Why ADVPN? This chapter details the main approaches taken by several vendors of IPsec VPN technologies to produce, from the respective IETF RFCs, meaningful solutions for customers to deploy in order to solve real world encryption problems It provides a basic summary of the relevant RFCs, the approaches that have emerged for deployment, and the issues with these approaches, and sets out the requirements for a new and different approach that is fulfilled by ADVPN The IETF IKEv2 Peer-to-Peer Model RFC 7296 is the specification for the Internet Key Exchange (IKE) protocol, currently designated as version 2, (IKEv2) RFC 7296 replaces RFCs 4306 and 5996, which in turn replaced the IKEv1 RFCs, 2407, 2408, and 2409 specifications RFC 7296 defines a control plane protocol to be used by IPsec peers to establish the services, cryptographic algorithms, and the keys necessary for each to maintain the correct state MORE? RFC 7296 can be read here: https://tools.ietf.org/html/rfc7296 RFC 7296 also defines a basic model whereby a system consisting of protected subnets, tunnel endpoints, and IPsec tunnels can be established for the purpose of protecting traffic in transit across untrusted networks, giving rise to three main use cases Gateway-to-Gateway Endpoint-to-Endpoint Endpoint-to-Gateway 10 Day One: ADVPN Design and Implementation In addition, tunnels can be established in one of two modes: tunnel or transport Tunnel mode is when the security gateways or protected endpoints provide security services to the datagrams by fully encapsulating them in a new IP layer, forming new addressing between the peers Transport mode is when only the payload of the IP packet is protected and no additional IP layer is required Use Case One In this first use case, or Security Gateway-to-Security Gateway, peers protect traffic on behalf of connected subnets via an IP overlay model using tunnel mode IPsec, as detailed in Figure 1.1 Figure 1.1 Security Gateway-to-Security Gateway IPsec VPNs NOTE Use Case One is the typical “secure router” model and it is the focus of this book The other two use cases are included in this chapter to provide a complete discussion Use Case Two In this use case Endpoint-to-Endpoint peers protect traffic with their own addresses without an IP overlay model using transport mode IPsec as detailed in Figure 1.2 This is the typical “secure host” model and is out of scope for this book because it does not involve security gateways Appendices 123 If you want to override the default ADCS database locations, so Here they are left to the default values Click Next: You’ve almost reached the point of no return Review the summary of the selections/settings made during the wizard Click Configure when ready: You’re almost done! Click Close Everything should now be configured If there are any errors, investigate and resolve them before proceeding The next few steps are to fine tune 124 Day One: ADVPN Design and Implementation CA Configuration for Certificate Revocation List Checking By default, ADCS will issue certificates to end entities with the Certificate Revocation List Distribution Point ("CRLDP", or simply "CDP") value set without an HTTP location This needs to be changed In Server Manager, click Tools > Certification Authority: Right-click on your CA in the left pane and click Properties: Appendices 125 Navigate to the Extensions tab Find the CRL location that begins with “http://” and click it once Ensure that Include in CRLs Clients use this to find Delta CRL locations and Include in the CDP extension of issued certificates options are checked In the book’s lab, we also unchecked all boxes in the ldap:// CRL location By default, the file:// location options are not checked It’s important to note that the HTTP URL defined here is embedded in the certificates issued by the CA In this book’s lab, using the default HTTP variables as follows: http:///CertEnroll/< DeltaCRLAllowed>.crl The resultant URL used in the CDP becomes: http://ca01.lab.jnprcbr local/CertEnroll/lab-CA01.crl Publish the IPsec (Offline) Certificate Template Within the Certification Authority management snap-in, right-click on Certificate Templates and navigate to New > Certificate Template to Issue: 126 Day One: ADVPN Design and Implementation Scroll down until you find the IPsec (Offline request) template Highlight it, and then click OK: SRX Configuration: Obtain and Load the CA Certificate Download the CA’s certificate by pointing your web browser at http:// yourserver/certsrv/ Click the link to Download a CA certificate, certificate chain, or CRL Choose the Base64 option and then click Download CA Certificate Save the resultant file (certnew.cer) to a known location Now, to get the certificate onto the SRX, you can either transfer the certnew.cer file using SCP or FTP as you would a Junos image, or you can use the method described below to paste it into a terminal session To transfer the certificate using the terminal method, open certnew.new in your favorite text editor It should look something like this: -BEGIN CERTIFICATE MIICazCCAfGgAwIBAgIQE3Ryv2zi6Z9BwW5yLzK4EzAKBggqhkjOPQQDAzBcMQsw CQYDVQQGEwJBVTEMMAoGA1UECBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcG A1UEChMQSnVuaXBlciBOZXR3b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwHhcNMTUw MTIyMDUyMTQ4WhcNMjAwMTIyMDUzMTM0WjBcMQswCQYDVQQGEwJBVTEMMAoGA1UE CBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcGA1UEChMQSnVuaXBlciBOZXR3 b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQq 0xaGCwhIwnwjHXXQzmjfVE8f/x5VmQHWpQbFUKtf0xOr4kbeRhqCUDgEBpxri8cz q+RDtOMSf4cGWWN+WiJRS/yvVPgKz5mp/Gknwxb7t1QkjITnSUEgfDLstCywg1Gj eDB2MAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTLcO58 AudRR9Mx2vCOjXrsd8G9NTASBgkrBgEEAYI3FQEEBQIDAgACMCMGCSsGAQQBgjcV AgQWBBTSi1+P17mnRXcyivXExfpGGzjhRTAKBggqhkjOPQQDAwNoADBlAjBGTGtD kGanQJQNsv3JF0fnnkldGyZGL4/rIBAOaVvBaxi6Bh0xAKLqg5EjK5Obt9ECMQDv O8bEXWpNlrORNUdXDnXzu6HIXhm0n22OoAm14V3wSBsdeiiM2PQgJa9H3GzH/l4= -END CERTIFICATE - Appendices 127 If it looks different, it may be that you downloaded the certificate in DER format instead Now, highlight and copy the entire contents of the file and switch to your terminal window: admin@srx550-01> start shell % cat >ca.txt -BEGIN CERTIFICATE MIICazCCAfGgAwIBAgIQE3Ryv2zi6Z9BwW5yLzK4EzAKBggqhkjOPQQDAzBcMQsw CQYDVQQGEwJBVTEMMAoGA1UECBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcG A1UEChMQSnVuaXBlciBOZXR3b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwHhcNMTUw MTIyMDUyMTQ4WhcNMjAwMTIyMDUzMTM0WjBcMQswCQYDVQQGEwJBVTEMMAoGA1UE CBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcGA1UEChMQSnVuaXBlciBOZXR3 b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQq 0xaGCwhIwnwjHXXQzmjfVE8f/x5VmQHWpQbFUKtf0xOr4kbeRhqCUDgEBpxri8cz q+RDtOMSf4cGWWN+WiJRS/yvVPgKz5mp/Gknwxb7t1QkjITnSUEgfDLstCywg1Gj eDB2MAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTLcO58 AudRR9Mx2vCOjXrsd8G9NTASBgkrBgEEAYI3FQEEBQIDAgACMCMGCSsGAQQBgjcV AgQWBBTSi1+P17mnRXcyivXExfpGGzjhRTAKBggqhkjOPQQDAwNoADBlAjBGTGtD kGanQJQNsv3JF0fnnkldGyZGL4/rIBAOaVvBaxi6Bh0xAKLqg5EjK5Obt9ECMQDv O8bEXWpNlrORNUdXDnXzu6HIXhm0n22OoAm14V3wSBsdeiiM2PQgJa9H3GzH/l4= -END CERTIFICATE % exit exit admin@srx550-01> Let’s step through this First, you’re dropping out of the Junos CLI into a shell prompt Next, you’re using the “cat” (concatenate) tool to redirect what you’re about to paste into a file named ca.txt Then, you’re pasting in the contents of the Base64-encoded CA certificate After the line containing the string -END CERTIFICATE -, type Control-D (^D) to finish the process Type exit to return to the Junos CLI You should now have a file named “ca.txt” in your home directory on the SRX Let’s confirm it: admin@srx550-01> file show ca.txt -BEGIN CERTIFICATE MIICazCCAfGgAwIBAgIQE3Ryv2zi6Z9BwW5yLzK4EzAKBggqhkjOPQQDAzBcMQsw CQYDVQQGEwJBVTEMMAoGA1UECBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcG A1UEChMQSnVuaXBlciBOZXR3b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwHhcNMTUw MTIyMDUyMTQ4WhcNMjAwMTIyMDUzMTM0WjBcMQswCQYDVQQGEwJBVTEMMAoGA1UE CBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcGA1UEChMQSnVuaXBlciBOZXR3 b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQq 0xaGCwhIwnwjHXXQzmjfVE8f/x5VmQHWpQbFUKtf0xOr4kbeRhqCUDgEBpxri8cz q+RDtOMSf4cGWWN+WiJRS/yvVPgKz5mp/Gknwxb7t1QkjITnSUEgfDLstCywg1Gj eDB2MAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTLcO58 AudRR9Mx2vCOjXrsd8G9NTASBgkrBgEEAYI3FQEEBQIDAgACMCMGCSsGAQQBgjcV AgQWBBTSi1+P17mnRXcyivXExfpGGzjhRTAKBggqhkjOPQQDAwNoADBlAjBGTGtD kGanQJQNsv3JF0fnnkldGyZGL4/rIBAOaVvBaxi6Bh0xAKLqg5EjK5Obt9ECMQDv O8bEXWpNlrORNUdXDnXzu6HIXhm0n22OoAm14V3wSBsdeiiM2PQgJa9H3GzH/l4= -END CERTIFICATE - 128 Day One: ADVPN Design and Implementation Okay, great! Now, you need to apply some PKI configuration in Junos At this point all you need to is to define a CA profile that can be used to associate with the certificate: admin@srx550-01> configure Entering configuration mode [edit] admin@srx550-01# set security pki ca-profile lab-root ca-identity lab-CA01 [edit] admin@srx550-01# commit and-quit Load the certificate: admin@srx550-01> request security pki ca-certificate load ca-profile lab-root filename ca.txt Fingerprint: a5:52:47:47:28:49:c9:95:da:83:0c:15:67:4b:0e:0c:bc:19:67:93 (sha1) ff:6a:4e:c7:15:98:5d:ab:61:ff:0f:f6:ab:39:c1:5b (md5) Do you want to load this CA certificate ? [yes,no] (no) yes CA certificate for profile lab-root loaded successfully Generate a Key Pair and Complete the Onboarding Process Generate an ECDSA-384 key pair: admin@srx550-01> request security pki generate-key-pair certificate-id srx550-01_0003 size 384 type ecdsa Generated key pair srx550-01_0003, key size 384 bits If you’ve configured syslog to look for PKI events, when you run this command, you should see a PKI syslog message similar to the following: Feb 27 11:09:18 srx550-01 pkid[1452]: %DAEMON-5-PKID_PV_KEYPAIR_GEN: A 384 bit ECDSA key-Pair has been generated for srx550-01_0003 Now generate a request for an X.509 certificate: admin@srx550-01> request security pki generate-certificate-request digest sha256 domain-name srx550-01.lab.jnprcbr.local certificate-id srx55001_0003 subject “DC=sec0003, CN=srx550-01.sec0003.lab.jnprcbr local, L=Canberra, ST=ACT, C=AU” Generated certificate request -BEGIN CERTIFICATE REQUEST MIIBqDCCASwCAQAwdDEXMBUGCgmSJomT8ixkARkWB3NlYzAwMDMxKzApBgNVBAMT Appendices 129 InNyeDU1MC0wMS5zZWMwMDAzbGFiLmpucHJjYnIubG9jYWwxETAPBgNVBAcTCENh bmJlcnJhMQwwCgYDVQQIEwNBQ1QxCzAJBgNVBAYTAkFVMHYwEAYHKoZIzj0CAQYF K4EEACIDYgAElKvwWTffQ235Rre5Aj/yF0Uyht8K7amjTRAxJSeKsx5pde9hemHc VbLHC7dBGBBiMURouI0CLRZyAHIGLa19m20IdR3G31B6zHTUAOduZHyqkeSa4CPS blvHSiznWD17oDkwNwYJKoZIhvcNAQkOMSowKDAmBgNVHREEHzAdghtzcng1NTAt MDEubGFiLmpucHJjYnIubG9jYWwwDAYIKoZIzj0EAwMFAANoADBlAjBraKeGjlui PFoTlyGqumEd5K24BzIeIiP3ZfmtGJ/rD6ChUyMSznVtitwPhgZbp54CMQC1BDfV A3/a97opaVDQv+4w7a+m63HasXttwF0gP721Mb/ii213v8EldHmXDZNNY1w= -END CERTIFICATE REQUEST Fingerprint: 00:95:5b:b7:89:da:46:2b:99:1b:cd:68:eb:72:f7:7a:99:c5:8b:9d (sha1) fe:b3:0d:9c:f3:3c:11:53:83:51:94:2b:bf:25:02:4e (md5) Submit the request to the CA via the web interface: Copy the text above, starting at the line containing the string -BEGIN CERTIFICATE REQUEST - and ending at the line containing the string -END CERTIFICATE REQUEST - Point your web browser at http://yourserver/certsrv/ Click the link to Request a certificate, then click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file In the Saved Request text box, paste in the certificate request From the Certificate Template drop-down, ensure that IPsec (Offline request) is selected Click Submit On the next screen, click the radio button next to Base64 encoded and then download the certificate The file will be named certnew.cer as before, so when you save it, give it a unique name (for example, srx550-01.cer) Using your preferred method (therefore, FTP/SCP or terminal), transfer this file to the SRX as you did with the CA certificate Now you’re ready to load the issued certificate: admin@srx550-01> request security pki local-certificate load certificate-id srx55001_0003 filename srx550-01_0003.cer Local certificate loaded successfully If you’ve configured syslog to look for PKI events, when you run this command, you should see a PKI syslog message similar to the following: Feb 27 11:21:52 srx550-01 pkid[1452]: %DAEMON-5-PKID_PV_CERT_LOAD: Certificate srx550-01_0003 has been successfully loaded Now you’re ready to configure ADVPN! 130 Day One: ADVPN Design and Implementation Appendix 2: OpenSSL as an Offline CA During the writing of this book some of our labs were completely isolated; in one instance, the entire lab was provisioned on a laptop with resources only sufficient to run the Junos vSRX images A work-around was found, and it turned out to be so useful during our testing that we decided to document it in this book It should be stressed, however, that this should only be used in a lab environment, as important CA functions such as certificate revocation are not by definition available for an offline CA In addition there is some manual cut and paste work, which is probably fine for a lab network, but in a production environment, certificate enrollment is a far superior solution The workaround consists of having OpenSSL instances running on a Linux host (the chosen version of Linux is Ubuntu 14.04) If you are new to public key infrastructure (PKI), going through these Appendices will give you insights into how the mechanics of PKI really work because due to this Appendice’s manual nature the steps take place at the most basic level Note that these steps can typically be abstracted and hidden by the CA provider’s service offerings Preparing the Linux Host to Be a CA A fresh install of Ubuntu has OpenSSL installed Go to directory/etc/ ssl and take a copy of the default OpenSSL configuration file: sudo cp openssl.cnf openssl.orig You need to edit the openssl.cnf file, using your favorite Linux editor, and add the following stanza to the configuration file: Dir = / This tells OpenSSL to work from the current directory to read the CA configuration files and where to place the generated certificates The other configuration item requiring adjustment is how the SRX generates certificates that are to be signed By default, modern versions of OpenSSL are expecting distinguished names to be in utf8only text format However the SRX generates its certificates in printablestring text format This becomes an issue when the CA tries to sign a certificate – by default it will try and match on stateorProvinceName and organizationName To work around this issue, modify the policy match stanza of the configuration file and change the stateorProvince- Appendices 131 Name and organizationName from match to optional as noted below: [ policy_match ] countryName = match stateOrProvinceName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional Alternatively the string mask can be set to assume printablestring as noted below: # This sets a mask for permitted string types There are several options # default: PrintableString, T61String, BMPString # pkix : PrintableString, BMPString (PKIX recommendation before 2004) # utf8only: only UTF8Strings (PKIX recommendation after 2004) # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings) # MASK:XXXX a literal mask value # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings string_mask = pkix Save the configuration file Decide what you want to call your CA In this example the CA is going to be called SuiteBCA You now need to build a directory structure that reflects this CA and the subdirectories (starting at the / etc/ssl part of the directory) for the various CA functions and then change into the directory: sudo mkdir –p SuiteBCA/{certs,newcerts} cd SuiteBCA The subdirectories names certs and newcerts are derived from the openssl.cnf file If you have changed the openssl.cnf file for those entries, the directories need to match When creating SRX certificates to be signed, not only you need a subject, you also need a domain name, email address, or IP address, which becomes the subject alternative name in the X509 certificate In this tutorial, the email name was chosen Create a new file called subalt.txt and create the subject alternative name: subjectAltName=email:mbarrett@juniper.net Save the file The next stage is to create a CA private key As the name of the CA implies, this CA was used to create certificates that could be used when encrypting with SuiteB algorithms, and in particular the Juniper 256bit SuiteB proposal set: sudo openssl ecparam –out ec_key.pem –name secp384r1 –genkey 132 Day One: ADVPN Design and Implementation This OpenSSL command creates a private key using the secp384r1 profile that uses the appropriate elliptic curve necessary so Juniper SuiteB proposal sets work correctly The next step is to create the CA certificate: sudo openssl req –x509 –new –days 3650 –key ec_key.pem –sha384 –out cacert.pem This OpenSSL command requests a new certificate to be created Use the private key you’ve just created and generate the CA certificate, which comes in pem format Again, to ensure compliance with Juniper’s currently implemented 256bit SuiteB algorithms, the secure hash sha384 must be specified Once you enter this command you will be prompted for the characteristics of the certificate, which include Country Name, State, Locality Name, Organization Name, Organization Unit, Common Name Like all good lab configurations, make sure your CA certificate doesn’t run out anytime soon, that being 10 years Keep the generated cacert.pem file handy as it will be required to be copied to each SRX that you want to use this CA as a signing authority The last stage of creating the CA is to seed the starting point for certificates – you want to create and ensure an index file exists for the certificates you will be creating: sudo echo 100 >serial touch index.txt That completes the configuration for OpenSSL as an offline CA Preparing the SRX The first stage of preparing the SRX is to create a PKI profile: security { pki { ca-profile SuiteB { ca-identity suiteB; revocation-check { disable; } } } In this particular case the profile is called SuiteB with a certificate authority identity of SuiteB As our CA is completely offline, it is important to disable revocation checking The next step is to load the CA’s certificate on the SRX The cacert.pem file generated in the creation of the CA needs to make its way onto the SRX file system The simplest way is to drop back to the shell on the SRX, and create the file via vi, and then cut and paste the cacert.pem file into the vi session and save it Appendices 133 Now, once the CA’s certificate is on the SRX, you need to associate that certificate with the profile just created In a lab context, the file was stored in root’s home directory so the file goes in /root/cacert.pem: request security pki ca-certificate load ca-profile SuiteB filename /root/cacert.pem Now that there is a CA certificate on the SRX, the generation of the SRX private/public key combination and signing request can begin The first stage is to generate the private/public key pair: Request security pki generate-key-pair generate-key-pair type ecdsa size 384 certificate_id srx550-1 Once again as the generation of the certificates are for a SuiteB implementation you need to specify the type as an elliptic curve, and because you want to use the Juniper SuiteB 256 proposal set, you must have a size of 384 TIP If you are planning on having multiple ADVPN instances, each running in its own routing instance, having sensible naming standards for the certificate IDs so you can readily identify the certificate is useful The final stage of preparing the SRX is to generate a certificate signing request with the key just created This stage is very important because it’s where you get to define the subject in the certificate This in turn is used to create the identifier that will be used to decide if the IKE SA will be accepted: request security pki generate-certicate-request certificate-id srx550-1 subject “DC=srx550-1.juniper.net,CN=srx550-1.juniper.net,OU=Base,O=Juniper,L=Canberra,ST=ACT, C=AU” email mbarrett@juniper.net Again, if you are going to be generating different certificates for different routing instances, ensure one element of the subject is used as a distinguisher In this case, the OU parameter has been chosen, and since this certificate is for the default routing instance, it’s called Base For the certificate request that resides in the routing instance, using the name of the routing instance would easily distinguish that certificate The final parameter is the Subject Alternative Name as built in the first section of setting up the OpenSSL CA On completion of the request, a certificate signing request will be generated on the SRX This needs to be captured to a file so it can then be taken to the CA to be signed By convention, the name of the file should be the certificate ID, with a csr extension – in this example, srx550-1.csr 134 Day One: ADVPN Design and Implementation Signing the SRX Certificate With the CA Place the certificate signing request file that was just created in the base directory of your CA on the Linux host Use the following OpenSSL command to sign the request: sudo openssl ca –in srx550-1.csr –out certs/srx550-1.pem –keyfile ec_key.pem –cert cacert.pem –md SHA384 –extfile subalt.txt Once again, as you are generating certificates for Juniper’s SuiteB 256 proposal set as currently implemented, the hash for the certificate must be SHA384-based as signified by the –md parameter The extfile parameter is the file that was created during the setup of the OpenSSL CA In the directory certs (one level below the CA’s base directory) will be the signed certificate that needs to go back to the SRX Once again, take a copy of this file (as you did before) and get it to the SRX The file will have a pem extension Loading the CA Signed Certificate on the SRX Certificate Use the method previously used to get the CA public key file onto the SRX, and so for the signed key for the SRX Assuming the file is stored in the root’s directory issue the following SRX command to install the signed certificate: request security pki local-certificate load certificate-id srx550-1 filename /root/ srx550-1.pem You now have a signed certificate installed in your SRX SRX IKE Configuration Example With a signed certificate created, configuration needs to be added to use the certificates In addition to the preceding CA profile, the IKE policy needs to reflect the certificate created Finally, the distinguished-name wildcard needs to be defined so you can match on the certificate details An example follows: ike { policy ikepol-advpn { mode main; certificate { local-certificate srx550-1; } proposal-set suiteb-gcm-256; } gateway hub-gw { Appendices 135 ike-policy ikepol-advpn; dynamic { distinguished-name { wildcard ST=ACT,O=Juniper; } ike-user-type group-ike-id; } local-identity distinguished-name; external-interface ge-0/0/0.0; advpn { partner { disable; } } version v2-only; } } To verify the certificates on the SRX, use the show security pki ca-certification ca-profile SuiteB detail command: Certificate identifier: SuiteB Certificate version: 3 Serial number: c50d29afe6c65a10 Issuer: Organization: Juniper, Organizational unit: Net, Country: AU, State: ACT, Locality: Canberra, Common name: UbuntuCA Subject: Organization: Juniper, Organizational unit: Net, Country: AU, State: ACT, Locality: Canberra, Common name: UbuntuCA Subject string: C=AU, ST=ACT, L=Canberra, O=Juniper, OU=Net, CN=UbuntuCA, emailAddress=mbarrett@ juniper.net Validity: Not before: 12- 2-2014 05:57 UTC Not after: 11-29-2024 05:57 UTC Public key algorithm: ecdsaEncryption(384 bits) 04:27:63:65:64:72:ee:c0:69:61:f9:a6:93:53:6d:a9:35:b7:60:31 85:94:df:45:35:1c:c1:7c:b3:84:ca:61:d2:c2:5e:e7:0c:75:62:ea 78:75:df:51:43:5a:e3:a1:d4:81:70:82:bb:b6:5d:3a:76:38:5d:d0 a2:da:f9:5a:16:e9:bc:9e:d8:ad:86:d4:88:03:84:c5:de:be:a1:5c 22:0f:21:b7:3c:58:f4:be:02:77:24:8d:e4:9b:4d:cd:25 Signature algorithm: ecdsa-with-SHA384 Fingerprint: 3e:82:62:34:77:33:b2:5a:30:00:50:3c:a9:9d:9e:6f:89:a6:d6:f1 (sha1) 00:d5:a8:56:05:f6:80:cb:26:b7:e4:1e:9e:ef:a2:55 (md5) Make sure the public key algorithm and signature algorithm are suitable for the ciphers you’ll use with a show security pki localcertificate certificate-id SRX550-01 detail command: Certificate identifier: srx550-1 Certificate version: 3 Serial number: 00001001 136 Day One: ADVPN Design and Implementation Issuer: Organization: Juniper, Organizational unit: Net, Country: AU, State: ACT, Locality: Canberra, Common name: UbuntuCA Subject: Organization: Juniper, Organizational unit: Base, Country: AU, State: ACT, Common name: srx550-01.juniper.net Subject string: C=AU, ST=ACT, O=Juniper, OU=Base, CN=srx550-01.juniper.net Alternate subject: mbarrett@juniper.net, fqdn empty, ip empty Validity: Not before: 12- 2-2014 06:39 UTC Not after: 12- 2-2015 06:39 UTC Public key algorithm: ecdsaEncryption(384 bits) 04:fc:97:41:31:a8:6d:65:9a:65:82:34:f0:e7:69:1f:d9:27:c8:f3 c6:9e:cb:8e:a1:df:c8:13:a9:1e:6c:8d:35:63:b8:94:5a:8d:55:20 32:ee:f7:56:45:62:ae:24:54:a5:a0:0c:6a:8f:39:fd:bf:5a:92:b8 46:c9:13:76:16:18:4c:b9:34:2c:a1:6c:0a:37:eb:71:1b:cf:4e:97 a5:42:08:15:1c:2b:25:44:2e:04:41:88:57:3c:eb:bf:14 Signature algorithm: ecdsa-with-SHA384 Fingerprint: 8c:1d:34:17:f1:1b:86:f2:03:0e:e8:7e:49:bb:30:15:ac:bd:e2:c9 (sha1) 6c:19:01:d5:9b:1f:56:01:7d:97:8c:b4:0b:c6:c8:d4 (md5) Auto-re-enrollment: Status: Disabled Next trigger time: Timer not started Now make sure the public key algorithm and signature algorithm are suitable for the ciphers you’ll use In addition, make sure the subject string is appropriate for what you’ll be matching on for your dynamic neighbors Let’s see what it looks like now when associations are created with the show sececurity ike security-associations command: Index State Initiator cookie Responder cookie Mode Remote Address 8096092 UP 632272c2d5b27286 41dd14abcb525543 IKEv2 192.168.66.1 The certificates on both sides of the exchange are okay with established IKE sessions Let’s look at this association in detail using the show security ike security-associations index detail command: IKE peer 192.168.66.11, Index 8096092, Gateway Name: hub-gw Auto Discovery VPN: Type: Static, Local Capability: Suggester, Peer Capability: Partner Suggester Shortcut Suggestions Statistics: Suggestions sent : 0 Suggestions accepted: 0 Suggestions declined: 0 Role: Responder, State: UP Initiator cookie: d4f3308d89b2973b, Responder cookie: d60cbace459377ad Exchange type: IKEv2, Authentication method: ECDSA-384-signatures Local: 192.168.66.1:500, Remote: 192.168.66.11:500 Lifetime: Expires in 27181 seconds Appendices 137 Peer ike-id: C=AU, ST=ACT, O=Juniper, OU=Base, CN=srx550-02.juniper.net Xauth user-name: not available Xauth assigned IP: 0.0.0.0 Algorithms: Authentication : hmac-sha384-192 Encryption : aes256-cbc Pseudo random function: hmac-sha384 Diffie-Hellman group : DH-group-20 Traffic statistics: Input bytes : 1362 Output bytes : 1323 Input packets: 2 Output packets: 2 IPsec security associations: 2 created, 0 deleted Phase 2 negotiations in progress: 1 Negotiation type: Quick mode, Role: Responder, Message ID: 0 Local: 192.168.66.1:500, Remote: 192.168.66.11:500 Local identity: C=AU, ST=ACT, O=Juniper, OU=Base, CN=srx550-01.juniper.net Remote identity: C=AU, ST=ACT, O=Juniper, OU=Base, CN=srx550-02.juniper.net Flags: IKE SA is created You can see the algorithms that are being used and the peer IKE identification Now that IKE is established, IPsec associations follow with the show security ipsec associations command: Total active tunnels: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway 67108870 ESP:aes-gcm-256/None 6a57b9c3 3132/ unlim - root 500 192.168.66.1 Summary Okay lab rats, it’s your turn to take this and run with it Have fun with ADVPN ... interoperability between ADVPN and non -ADVPN capable nodes, as non -ADVPN nodes will not be expecting to receive ADVPN messages Other capabilities outlined in the RFC standard (Trusted Suggester, and fully qualified... binding the IPsec policy and respective IKE gateway definition 28 Day One: ADVPN Design and Implementation The proposal and policy configurations for both the suggester and partner should be very... Jinesh Doshi Thanks to the main authors, Mark and Dale, and to our reviewers Bill Shelton, Gavin Thirlwall, and Johan Andersson, and editors Patrick, Nancy, and Karen vi Welcome to Day One This book