Get Started with BIG-IP and BIG-IQ Virtual Edition (VE) Trial
Welcome to the BIG-IP and BIG-IQ trials page! This will be your jumping off point for setting up a trial version of BIG-IP VE or BIG-IQ VE in your environment. As you can see below, everything you’ll need is included and organized by operating environment — namely by public/private cloud or virtualization platform. To get started with your trial, use the following software and documentation which can be found in the links below. Upon requesting a trial, you should have received an email containing your license keys. Please bear in mind that it can take up to 30 minutes to receive your licenses. Don't have a trial license?Get one here. Or if you're ready to buy, contact us. Looking for other Resourceslike tools, compatibility matrix... BIG-IP VE and BIG-IQ VE When you sign up for the BIG-IP and BIG-IQ VE trial, you receive a set of license keys. Each key will correspond to a component listed below: BIG-IQ Centralized Management (CM) — Manages the lifecycle of BIG-IP instances including analytics, licenses, configurations, and auto-scaling policies BIG-IQ Data Collection Device (DCD) — Aggregates logs and analytics of traffic and BIG-IP instances to be used by BIG-IQ BIG-IP Local Traffic Manager (LTM), Access (APM), Advanced WAF (ASM), Network Firewall (AFM), DNS — Keep your apps up and running with BIG-IP application delivery controllers. BIG-IP Local Traffic Manager (LTM) and BIG-IP DNS handle your application traffic and secure your infrastructure. You’ll get built-in security, traffic management, and performance application services, whether your applications live in a private data center or in the cloud. Select the hypervisor or environment where you want to run VE: AWS CFT for single NIC deployment CFT for three NIC deployment BIG-IP VE images in the AWS Marketplace BIG-IQ VE images in the AWS Marketplace BIG-IP AWS documentation BIG-IP video: Single NIC deploy in AWS BIG-IQ AWS documentation Setting up and Configuring a BIG-IQ Centralized Management Solution BIG-IQ Centralized Management Trial Quick Start Azure Azure Resource Manager (ARM) template for single NIC deployment Azure ARM template for threeNIC deployment BIG-IP VE images in the Azure Marketplace BIG-IQ VE images in the Azure Marketplace BIG-IQ Centralized Management Trial Quick Start BIG-IP VE Azure documentation Video: BIG-IP VE Single NIC deploy in Azure BIG-IQ VE Azure documentation Setting up and Configuring a BIG-IQ Centralized Management Solution VMware/KVM/Openstack Download BIG-IP VE image Download BIG-IQ VE image BIG-IP VE Setup BIG-IQ VE Setup Setting up and Configuring a BIG-IQ Centralized Management Solution Google Cloud Google Deployment Manager template for single NIC deployment Google Deployment Manager template for threeNIC deployment BIG-IP VE images in Google Cloud Google Cloud Platform documentation Video:Single NIC deploy inGoogle Other Resources AskF5 Github community(f5devcentral,f5networks) Tools toautomate your deployment BIG-IQ Onboarding Tool F5 Declarative Onboarding F5 Application Services 3 Extension Other Tools: F5 SDK (Python) F5 Application Services Templates (FAST) F5 Cloud Failover F5 Telemetry Streaming Find out which hypervisor versions are supported with each release of VE. BIG-IP Compatibility Matrix BIG-IQ Compatibility Matrix Do you haveany comments orquestions? Ask hereWelcome to the F5 BIG-IP Migration Assistant - Now the F5 Journeys App
The older F5 BIG-IP Migration Assistant is deprecated and is replaced by F5 Journeys. Welcome to the F5 Journeys App - BIG-IP Upgrade and Migration Utility F5 Journeys App Readme @ Github What is it? The F5® Journeys BIG-IP upgrade and migration utility is a tool freely distributed by F5 to facilitate migrating BIG-IP configurations between different platforms. F5 Journeys is a downloadable assistant that coordinates the logistics required to migrate a BIG-IP configuration from one BIG-IP instance to another. Why do I need it? JOURNEYS is an application designed to assist F5 Customers with migrating a BIG-IP configuration to a new F5 device and enable new ways of migrating. Supported journeys: Full Config migration - migrating a BIG-IP configuration from any version starting at 11.5.0 to a higher one, including VELOS and rSeries systems. Application Service migration - migrating mission critical Applications and their dependencies to a new AS3 configuration and deploying it to a BIG-IP instance of choice. What does it do? It does a bunch of stuff: Loading UCS or UCS+AS3 source configurations Flagging source configuration feature parity gaps and fixing them with provided built-in solutions Load validation Deployment of the updated configuration to a destination device, including VELOS and rSeries VM tenants Post-migration diagnostics Generating detailed PDF reports at every stage of the journey Full config BIG-IP migrations are supported for software paths according to the following matrix: DEST X 11.x 12.x 13.x 14.x 15.x 16.x <11.5 X X X X^ X^ 12.x X X X X^ SRC 13.x X X X 14.x X X X 15.x X X 16.x How does it work? F5 Journeys App manages the logistics of a configuration migration. The F5 Journeys App either generates or accepts a UCS file from you, prompts you for a destination BIG-IP instance, and manages the migration. The destination BIG-IP instance has atmshcommand that performs the migration from a UCS to a running system. F5 Journeys uses thistmshcommand to accomplish the migration using the platform-migrate option (see more details K82540512) . The F5 Journeys App prompts you to enter a source BIG-IP (or upload a UCS file), the master key password, and destination BIG-IP instance. Once the tool obtains this information, it allows you to migrate the source BIG-IP configuration to the destination BIG-IP instance either entirely or in a per-application depending what you choose. Where do I obtain it? F5 Journeys App Readme @ Github What can go wrong? Bug reporting Let us know if something went wrong. By reporting issues, you support development of this project and get a chance of having it fixed soon. Please use bug template available here and attach the journeys.log file from the working directory ( /tmp/journeys by default) Feature requests Ideas for enhancements are welcome here For questions or furtherdiscussion please leave your comments below. Enjoy!Building an OpenSSL Certificate Authority - Creating Your Root Certificate
Creating Your Root Certificate Authority In our previous article, Introductions and Design Considerations for Eliptical Curveswe covered the design requirements to create a two-tier ECC certificate authority based on NSA Suite B's PKI requirements. We can now begin creating our CA's root configuration. Creating the root CArequires us to generate a certificate and private key,since this is the first certificate we're creating, it will be self-signed. The root CA will not sign client and server certificates, it's job it only to create intermeidary certificates and act as the root of our chain of trust. This is standard practice across the public and private PKI configurations and so too should your lab environments. Create Your Directory Structure Create a directory to store your root CA pair and config files. # sudo bash # mkdir /root/ca Yep, I did that. This is for a test lab and permissions may not match real world requirements. I sudoed into bash and created everything under root; aka playing with fire. This affects ownership down the line if you chmod private key files and directoriesto user access only so determine for yourself what user/permission will be accessing files for certificate creation. I have a small team and trust them with root within a lab environment (snapshots allow me to be this trusting). Create your CA database to keep track of signed certificates # cd /root/ca # mkdir private certs crl # touch index.txt # echo 1000 > serial We begin by creating a working root directory with sub directories for the various files we'll be creating. This will allow you to apply your preferred security practices should you choose to do so. Since this is a test lab and I am operating as root, I won't be chmod'ing anything today. Create Your OpenSSL Config File OpenSSLuses configuration files to simplify/template the components of a certificate. Copy the GIST openssl_root.cnf file to /root/ca/openssl_root.cnf which is already prepared for this demo. For the root CA certificate creation, the [ CA ] section is required and will gather it's configuration from the [ CA_default ] section. [ ca ] # `man ca` default_ca = CA_default The [CA_default] section in the openssl_root.cnf file contains the variables OpenSSL will use for the root CA. If you're using alternate directory names from this demo, update the file accordingly. Note the long values for default days (10 years) as we don't care about renewing the root certificate anytime soon. [ CA_default ] # Directory and file locations. dir = /root/ca certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/certs database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # The root key and root certificate. private_key = $dir/private/ca.cheese.key.pem certificate = $dir/certs/ca.cheese.crt.pem # For certificate revocation lists. crlnumber = $dir/crlnumber crl = $dir/crl/ca.cheese.crl.pem crl_extensions = crl_ext default_crl_days = 3650 # SHA-1 is deprecated, so use SHA-2 or SHA-3 instead. default_md = sha384 name_opt = ca_default cert_opt = ca_default default_days = 3650 preserve = no policy = policy_strict For the root CA, we define [policy_strict] which will later force the intermediary's certificateto match country, state/province, and organization name fields. [ policy_strict ] The root CA should only sign intermediate certificates that match. # See POLICY FORMAT section of `man ca`. countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional The [ req ] section is used for OpenSSL certificate requests. Some of the values listed will not be used since we are manually specifying them during certificate creation. [ req ] # Options for the `req` tool (`man req`). default_bits = 4096 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 is deprecated, please use SHA-2 or greater instead. default_md = sha384 # Extension to add when the -x509 option is used. x509_extensions = v3_ca I pre-populate the [ req_distinguished_name ] section with values I'll commonly used to save typing down the road. [ req_distinguished_name ] countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name 0.organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address # Optionally, specify some defaults. countryName_default = US stateOrProvinceName_default = WA localityName_default = Seattle 0.organizationName_default = Grilled Cheese Inc. organizationalUnitName_default = Grilled Cheese Root CA emailAddress_default = grilledcheese@yummyinmytummy.us The [ v3_ca ] section will further define the Suite B PKI requirements, namely basicConstraints and acceptable keyUsage values for a CA certificate. This section will be used for creating the root CA's certificate. [ v3_ca ] # Extensions for a typical CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign Selecting the Suite B compliant elliptical curve We're creating a Suite B infrastructure so we'll need to pick an acceptable curve following P-256 or P-384. To do this, run the following OpenSSLcommand: openssl ecparam -list_curves This will give you a long list of options but which one to pick? Let's isolate the suites within the 256 & 384 prime fields; we can grep the results for easier curve identification. openssl ecparam -list_curves | grep '256\|384' And we get the following results (your results may vary depending on the version of OpenSSL running): # openssl ecparam -list_curves | grep '256\|384' secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field brainpoolP256r1: RFC 5639 curve over a 256 bit prime field brainpoolP256t1: RFC 5639 curve over a 256 bit prime field brainpoolP384r1: RFC 5639 curve over a 384 bit prime field brainpoolP384t1: RFC 5639 curve over a 384 bit prime field I am going to use secp384r1 as my curve of choice. It's good to mention that RFC5480 notes secp256r1 (not listed) is referred to as prime256v1 for this output's purpose. Why not use something larger than 384? Thank Google. People absolutely were using secp521r1 then Google dropped support for it (read Chromium Bug 478225 for more). The theoryis since NSA Suite B PKI did not explicitly call out anything besides 256 or 384, the Chromium team quietly decided it wasn't needed and dropped support for it. Yea... it kinda annoyed a few people. So to avoid future browser issues, we're sticking with what's defined in public standards. Create the Root CA's Private Key Using the names defined in the openssl_root.cnf's private_key value and our selected secp384r1 ECC curve we will create and encrypt the root certificates private key. # openssl ecparam -genkey -name secp384r1 | openssl ec -aes256 -out private/ca.cheese.key.pem read EC key writing EC key Enter PEM pass phrase: ****** Verifying - Enter PEM pass phrase: ****** Note:The ecparam function within OpenSSL does not encrypt the private key like genrsa/gendsa/gendh does. Instead we combined the private key creation (openssl ecparam) with a secondary encryption command (openssl ec) to encrypt private key before it is written to disk. Keep the password safe. Create the Root CA's Certificate Using the new private key, we can now generate our root'sself-signed certificate. We do this because the root has no authority above it to request trust authority from;it is the absolute source of authority in our certificate chain. # openssl req -config openssl_root.cnf -new -x509 -sha384 -extensions v3_ca -key private/ca.cheese.key.pem -out certs/ca.cheese.crt.pem Enter pass phrase for private/ca.cheese.key.pem: ****** You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Root CA]: Common Name []:Grilled Cheese Root Certificate Authority Email Address [grilledcheese@yummyinmytummy.us]: Using OpenSSL we can validate the Certificate contents to ensure we're following the NSA Suite B requirements. # openssl x509 -noout -text -in certs/ca.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: ff:bd:f5:2f:c5:0d:3d:02 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Aug 22 23:53:05 2017 GMT Not After : Aug 20 23:53:05 2027 GMT Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:a6:b7:eb:8b:9f:fc:95:03:02:20:ea:64:7f:13: ea:b7:75:9b:cd:5e:43:ca:19:70:17:e2:0a:26:79: 0a:23:2f:20:de:02:2d:7c:8f:62:6b:74:7d:82:fe: 04:08:38:77:b7:8c:e0:e4:2b:27:0f:47:01:64:38: cb:15:a8:71:43:b2:d9:ff:ea:0e:d1:c8:f4:8f:99: d3:8e:2b:c1:90:d6:77:ab:0b:31:dd:78:d3:ce:96: b1:a0:c0:1c:b0:31:39 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Subject Key Identifier: 27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:77:a1:f9:e2:ab:3a:5a:4b:ce:8d:6a:2e:30:3f: 01:cf:8e:76:dd:f6:1f:03:d9:b3:5c:a1:3d:6d:36:04:fb:01: f7:33:27:03:85:de:24:56:17:c9:1a:e4:3b:35:c4:a8:02:31: 00:cd:0e:6c:e0:d5:26:d3:fb:88:56:fa:67:9f:e9:be:b4:8f: 94:1c:2c:b7:74:19:ce:ec:15:d2:fe:48:93:0a:5f:ff:eb:b2: d3:ae:5a:68:87:dc:c9:2c:54:8d:04:68:7f Reviewing the above we can verify the certificate details: The Suite B Signature Algorithm: ecdsa-with-SHA384 The certificate date validity when we specificed -days 3650: Not Before: Aug 22 23:53:05 2017 GMT Not After : Aug 20 23:53:05 2027 GMT The Public-Key bit length: (384 bit) The Issuer we defined in the openssl_root.cnf: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority The Certificate Subject, since this is self-signed, refers back to itself: Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority The eliptical curve used when we created the private key: NIST CURVE: P-384 Verify the X.509 v3 extensions we defined within the openssl_root.cnf for a Suite B CA use: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign The root certificate and private key are now compete and we have the first part of our CA complete. Step 1 complete! In our next article we willcreate the intermediary certificate to complete the chain of trust in our two-tier hierarchy.Building an OpenSSL Certificate Authority - Configuring CRL and OCSP
Certificate Revocation Lists We completed reviewing our PKI design considerations and createdroot and intermediary certificates completeing our two-tier certificate authority. Now we'll createcertificate revocation configurations to comply withNSA Suite B PKI. A certificate revocation list (CRL) is a published list of revoked certificates issued and updated by the certificate authority who signed them. Clients like your internet browser, will check the certificate's CRL URI to find out if the certificate is valid. When a certificate is revoked, the CRL is updated to reflect the revokation and published accordingly. Lists are not the most efficient way to maintain a record of revocation in high volume scenarios so some application vendors have deprecated their use in favor of online certificate status protcol (OCSP). We still needa CRL configuraiton as it's still common and recommended for backward compatibility. Previously we created a CRL URI via the openssl_intermediary.cnf when creating the intermediary certificate. This was an exercise in anticipation of us creating the CRL. Don't forgetwe're adhering to NSA's Suite B PKI so we have to remember: Every Suite B certificate and CRL MUST be signed using ECDSA And certificate and CRL MUST be hashed using SHA-256 or SHA-384, matched to the size of the signing CA's key The OpenSSL configuration file object [ server_cert ] includes crlDistributionPoints = @crl_info which directs the OpenSSL to: [crl_info] URI.0 = http://crl.grilledcheese.us/whomovedmycheese.crl This allows us to enter multiple CRL distribution points for redundancy. Create the CRL # cd /root/ca # openssl ca -config intermediate/openssl_intermediate.cnf -gencrl -out intermediate/crl/whomovedmycheese.crl Using configuration from intermediate/openssl_intermediate.cnf Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: ****** Validate the CRL with OpenSSL # openssl crl -in intermediate/crl/whomovedmycheese.crl -noout -text Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: ecdsa-with-SHA384 Issuer: /C=US/ST=WA/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=Grilled Cheese Inc. Intermediary Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us Last Update: Aug 24 23:21:38 2017 GMT Next Update: Feb 20 23:21:38 2018 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 CRL Number: 4097 No Revoked Certificates. Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:7b:e4:08:01:06:60:c8:e8:c8:fb:a7:e8:49:7b: bf:ee:a6:a6:19:8f:93:67:6c:15:25:bb:c0:d2:ad:c1:ff:05: d4:73:e0:72:f0:35:cd:64:35:8b:83:e7:7c:47:ed:ea:02:31: 00:d4:3c:30:7c:00:73:b6:93:34:3e:1d:96:8f:ba:8a:9b:21: 3e:ff:36:95:2c:e9:6e:e9:4b:9c:6c:49:1d:fd:ba:6a:75:70: 41:a5:5e:67:4d:ca:04:2c:c5:37:46:52:91 Yesit was that easy. The CRL file will reside at the URI you specified within the openssl_intermediary.cnf . Online Certificate Status Protocol The online certificate status protocol (OCSP) is used to check x.509 certificates revocation status. This is the preferred method over CRL by utilizing OCSP responders to return a positive, negative, or unknown status. This provides a faster response for the revocation check versus parsing potentially bulky CRL files. The OCSP responder must be signed by the same CA that issued the certificate being validated. OCSP stapling further improves certificate revocation checking by allowing the server hosting the certificate in question to provide a time-stamped response on behalf of the OCSP responder. Additions to the x.509 v3 extensions would require an OCSP stapled response during TLS negotiation or the connection would be terminated (unless an unknownstatus or no response is returned). Setting up an OCSP responder equires a server with our OCSP certificate in play and is out of scope for this article. OCSP configuration data is already present in our /root/ca/intermediate/openssl_intermediate.cnf so when the intermediary certificate was created, it referenced theconfiguration through the [ v3_intermediate_ca ] extension authorityInfoAccess = @ocsp_info. [ocsp_info] caIssuers;URI.0 = http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP;URI.0 = http://ocsp.grilledcheese.us/ Create the OCSP key & certificate Just like the intermediary CA, we'll generate the key and CSR in one line, using the same secp384r1 elliptical curve during root and intermediary CA creation. # cd /root/ca # openssl req -config intermediate/openssl_server.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/ocsp.cheese.key.pem -out intermediate/csr/ocsp.cheese.csr.pem -extensions server_cert Generating an EC private key writing new private key to 'intermediate/private/ocsp.cheese.key.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Intermediary CA]: Common Name []:ocsp.grilledcheese.us Email Address [grilledcheese@yummyinmytummy.us]: Sign the CSR with our Intermediary Certificate Authority # openssl ca -config intermediate/openssl_intermediate.cnf -extensions ocsp -days 365 -notext -md sha384 -in intermediate/csr/ocsp.cheese.csr.pem -out intermediate/certs/ocsp.cheese.crt.pem Using configuration from intermediate/openssl_intermediate.cnf Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4103 (0x1007) Validity Not Before: Aug 28 22:23:14 2017 GMT Not After : Aug 28 22:23:14 2018 GMT Subject: countryName = US stateOrProvinceName = WA localityName = Seattle organizationName = Grilled Cheese Inc. organizationalUnitName = Grilled Cheese Intermediary CA commonName = ocsp.grilledcheese.us emailAddress = grilledcheese@yummyinmytummy.us X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 55:96:45:08:3E:BA:6A:F7:1C:A2:5A:4E:5C:BB:63:65:44:8F:DD:4B X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing Certificate is to be certified until Aug 28 22:23:14 2018 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Verify the certificate's usage is set for OCSP # openssl x509 -noout -text -in intermediate/certs/ocsp.cheese.crt.pem X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing OCSP Stapling and Beyond OpenSSLdoes support operating as an OCSP responder. Per OpenSSL's OCSP man page, running their OCSP server is benefitial for test and demo purposes and is not recommended forproduction OCSP responder use. Other PKI vendors have more robust OCSP management capabilitiesintegratinginto CMS web solutions. Since most clients carry on with a certificates duty if OCSP is unavailablethis shouldn't concern us for testing purposes. If you want to setup OCSP stapling DevCentral's Jason Rahm has a guide on setting up OCSP Stapling for use within the virtual server interfaces if you're so inclined to enable BIG-IP for these features. Now we've completed a basic CRL and OCSP configuration, our clients (web browsers) shouldn't complain and we can move on to the fun part, creating server certificates!
BIG-IP integration with AWS Gateway Load Balancer - Overview
Introduction With the release of TMOS version 16.1,BIG-IP now supportsAWS Gateway Load Balancer(GWLB). With this integration we are making it much easier and simpler to insert BIG-IP security services into an AWS environment while maintaining high availability and supporting elastic scalability of the BIG-IP's. When to use GWLB? F5 BIG-IP delivers a wide range of application and security services. Depending on the service and other requirements the BIG-IP'sare typically deployed in one of two modes:Networkmode orProxymode. Important: GWLB is only applicabletoday with Network deployment mode. First, you should identifywhich deployment mode is relevant for you: Network(GWLB Supported) Common use cases: Network firewall, DDoS protection, Transparent WAF Flowtransparency is maintained (no source or destination NAT) Directing traffic to the BIG-IP's is done using routing by the network, making sure traffic goes back to the same BIG-IP in order to maintain traffic symmetry is also based on routing Proxy(NotGWLB Supported) Providingingress services to the application (WAF,LB, L7 DDoS, Bot protection), services are applied to an application specific virtual server on the BIG-IP The BIG-IP SNAT (source NAT) managesthe traffic to ensure that the return traffic arrives at the same BIG-IP thus maintaining traffic symmetry Directing user'straffic to the BIG-IP's is usually done using DNS. AFQDN will map to a specific virtual server on the BIG-IP. Important:GWLB doesnotsupport proxy devices in theinspection zone. Traffic flow must remain unchanged by the inspection device, for more details see:https://aws.amazon.com/blogs/networking-and-content-delivery/integrate-your-custom-logic-or-appliance-with-aws-gateway-load-balancer/). Existing challenges of BIG-IP Network deployment without GWLB Let's examine two scenarios in which we use the BIG-IP for inspecting network traffic: Ingress/Egress protection:In this scenario, we want to inspect all traffic coming into and going out of theAWS network. The security services that are most relevant for this scenario are: Firewall, DDOS protection, WAF andIPS. East west (Inter VPC / networks) protection: In this scenario we want to inspectalltraffic between VPC's and between on-prem to VPC's. Themost common security services used areFirewall and IPS. In the two scenarios mentioned above, we need to ensure the relevant flows are routed to the BIG-IP. We will also need to verify that traffic is symmetric – meaning any flow that was sent to the BIG-IP must also return fromthe same BIG-IP. Today, without GWLB,our methodof getting traffic to the BIG-IP is tomanipulate the routing tables accordingly. AWS's routing tables accepts an ENI (Elastic Network Interface, a Network interface of an EC2 instance running a BIG-IP) as the 'gateway' for a specific route. Since routing tables only accepts asingleENI, we can only send traffic to a single BIG-IP instance -which of course creates a single point of failure. We can further improve this design by leveraging F5's Cloud Failover Extension (CFE) which allows us to create an active/standby pair. TheCFE will automatically manipulate the route tables to always point traffic at the ENI of the active device. You can read more on this design here:https://clouddocs.f5.com/products/extensions/f5-cloud-failover/latest/userguide/aws.html?highlight=route In summary, the network deployment of the BIG-IP in AWS has the following challenges: Limited scale - Throughput, concurrent connections etc. as only a single device processes the traffic Unoptimized compute – Passive device sits idle Mixed admin domains – BIG-IP's are deployed in the same VPC as the workloads it is protecting, routing table changes are controlled by F5's CFE which is not always wanted or possible How GWLB works with BIG-IP To understand how AWS GWLB works, let'sstart by taking a closer look at the GWLB. We can break down the GWLB functionality into two main elements: On the frontend:GWLB presents itself as a next-hop L3 Gateway to manage traffic transparently. GWLB uses a new component:GWLB endpoint. This endpoint acts as an ENI (Elastic Network Interface) of the GWLB. The only way of sending traffic to GWLB is through this endpoint, therefore it is deployed in a VPC thatconsumesthe security services (i.e. theConsumer VPC). Admin domain separation:The GWLB and BIG-IP fleet are deployed in their own VPC (Security VPC). One GWLB can receive and inspect traffic from many VPC's (findmore detailon design patterns in the 'Deployments' section) On the backend:GWLB is like a L4 Load Balancer, very similar to NLB (Network Load Balancer) Provides traffic distribution across a fleet of BIG-IP instances. Routes flows and assignsthem to specific BIG-IP for stateful inspection. Performs health-checks of the BIG-IP's, and routes traffic to healthy BIG-IP's only. Traffic is sent over a L3 tunnel using the GENEVE protocol (Requires BIG-IP version 16.1 and above) BIG-IP integration details: Requirements: BIG-IP version 16.1 and above BIG-IP traffic flow: The BIG-IP must bedeployed inthe same VPC as the GWLB. BIG-IP receives traffic from GWLB over a GENEVE tunnel that uses the BIG-IPs private ip address. Next, we create a virtual server that is enabled on the new tunnel. The new tunnel gets the traffic from GWLB, decapsulates it and then it gets processed by the inspection virtual server. After the virtual server processes the packet and applies the definedsecurity profiles, it needs to forward the packet back to the tunnel. The way to 'Force' traffic back into the tunnel is to create a fake node that 'lives' inside the tunnel and use it as the target pool of the virtual server. Once the tunnel interface receives the packets from the virtual server, it encapsulates them with GENEVE and forwards it back to GWLB. The following diagram describes the traffic flow within a specific BIG-IP device: Considerations and known issues: Traffic flows inside the 'inspection zone' must remain unchanged. i.e, no change in the packet's 5 tuple is allowed. All virtual servers are supported as long as the 5 tuple of the packet is maintained. That might require changing some configurations, for example Disable the default 'address translation' feature of a 'standard' virtual server. Set the 'source port' setting to 'Preserve strict' Payload manipulation is supported as long as the packet's 5 tuple is maintained Some examples: HTTP rewrites AWAF blocking responses – AWAF responds with a 'blocking page' High Availability When a BIG-IP instance fails in the target group, GWLB continue to sendexistingflows to the failed instance. Onlynew connectionswill be directed to a new instance. Deploy BIG-IP instances across availability zones according to the desired AZ availability requirements. The Default behavior for GWLB is to keep traffic in the same AZ, meaning traffic that was received on an endpoint in AZ1 will only forward traffic to instances in AZ1. That behavior is controlled by the 'CrossZoneLoadBalancing' flaghttps://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html If you do change the 'CrossZoneLoadBalancing' flag, keep in mind that GWLB will distribute traffic across AZ's even when all instances are healthy andwill incur cross-AZtraffic costs. Flow timeout GWLB has its own protocol timeouts (350 seconds for TCP, 120 for UDP). the timeout values on the BIG-IP must be smaller then the ones on GWLB - BIG-IP uses 300 seconds for TCP and 60 for UDP by default. With the GWLB integration you can now create an elastic group of BIG-IP's that will be exposed to the rest of the AWS network using AWS native networking constructs. GWLB is responsible for distributing the traffic evenly between the group while maintaining flow affinity so that each flow will always be routed to the same BIG-IP in the group and thus solving the symmetric flows without requiring anySNAT. The security inspection zone can be deployed in its own VPC, allowing better administrative separation. Exposing the inspection service is done using VPC endpoints, those endpoints are tied to the GWLB and can be used as the target of different routing tables (TGW, Ingress, subnets). Summary The BIG-IP andGWLB integration enables the industryleading BIG-IPsecurity serviceswith the following benefits: Elastic scalability:Scale your deployment based on your actual usage. Horizontally scale your BIG-IP's. Simplified connectivity:Leverage AWS native networking constructs to 'insert' BIG-IP security services in different traffic flows (North-South, East-West) Cost effectiveness:Consolidate BIG-IP's deployments and size the deploymentbased on actual usage Next steps: Check out the next articles in this series - Ingress/Egress VPC inspection with BIG-IP and GWLB deployment pattern Ingress/Egress and inter VPC inspection with BIG-IP and GWLB deployment pattern Test the integration yourself - Check out our self-service lab that you can deploy in your own AWS account(Fully automated deployment using Terraform): https://github.com/f5devcentral/f5-digital-customer-engagement-center/tree/main/solutions/security/ingress-egress-fw https://github.com/f5devcentral/f5-digital-customer-engagement-center/tree/main/solutions/security/ingress-egress-inter-vpc-fw-gwlbBuilding an OpenSSL Certificate Authority - Creating Your Intermediary Certificate
Creating Your Intermediary Certificate Authority Previously we created the first part of our OpenSSL CA by building our root certificate. We are now ready to complete our CA chain by creating and signing the intermediary certificate.The intermediary will beresponsible for signing client and server certificate requests. It acts as an authoritative proxy for the root certificate hence the name intermediary. The chain of trust will extend from the root certificate to the intermediary certificate down to the certificates you'll deploy within your infrastructure. Create your directory structure Create a new subdirectory under /root/ca to segregate intermediary files our root configuration . # sudo bash # mkdir /root/ca/intermediate We're creating the same directory structure previously used under /root/ca within /root/ca/intermediary . It's your decision if you if you want to do something different. Some of my best friends are flat directory structures and we don't judge personal practices. Create your intermediary CA database to keep track of signed certificates # cd /root/ca/intermediate # mkdir certs crl csr private # touch index.txt # echo 1000 > serial Create a crlnumber file for the intermediary CA to use # echo 1000 > /root/ca/intermediate/crlnumber Similar to the earlier serial statement, this will create the crlnumber file and start the numerical iteration at 1000. This will be used for future certificate revocation needs. Create your OpenSSL intermediary config file Copy the GIST openssl_intermediate.cnf file to /root/ca/intermediate/openssl_intermediate.cnf and modify the contents for your own naming conventions. Similar to the root_ca.cnf , the [CA] is required and will gather it's configuration from the [CA_default] section. Changes to the [int_ca] include: [ CA_default ] # Directory and file locations. dir = /root/ca/intermediate private_key = $dir/private/int.cheese.key.pem certificate = $dir/cers/int.cheese.crt.pem crlnumber = $dir/crlnumber crl = $dir/crl/int.cheese.crl.pem crl_extensions = crl_ext policy = policy_loose We have new certificate names for our intermediary use and define policy_loose so future certificate requests don't have to match country, state/province, or organization. Create the Intermediary's Private Key and Certificate Signing Request Similar to the root certificate, we're following the NSA Suite B requirements and matching the root's elliptical curve, secp384r1. We'll alsocreate the CSR and private key all in one line, making your scripts and life a bit easier. # cd /root/ca # openssl req -config intermediate/openssl_intermediate.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/int.cheese.key.pem -out intermediate/csr/int.cheese.csr Generating an EC private key writing new private key to 'intermediate/private/int.cheese.key.pem' Enter PEM pass phrase: ****** Verifying - Enter PEM pass phrase: ****** ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Intermediary CA]: Common Name []:Grilled Cheese Inc. Intermediary Certificate Authority Email Address [grilledcheese@yummyinmytummy.us]: Sign the certificate request with the root certificate and use the openssl_intermediate.cnf config file to specify the [v3_intermediate_ca] extension instead of the [v3_ca] as we did for the root. The openssl_intermediate.cnf has a few changes which we need to note. [ v3_intermediate_ca ] # Extensions for a typical intermediate CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign crlDistributionPoints = @crl_info authorityInfoAccess = @ocsp_info [crl_info] URI.0 = http://crl.grilledcheese.us/whoremovedmycheese.crl [ocsp_info] caIssuers;URI.0 = http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP;URI.0 = http://ocsp.grilledcheese.us/ The Certificate Revocation List (crl) and Online Certificate Status Protocol (OCSP) should be included within the intermediary certificate. This lets systems know where check and see if the intermediary certificate was revoked by the root at any given time. We will cover this in detail later and browsers do not necessarily check the intermediary certificates for revocation, but they absolutely do for the site certificates. We're adding CRL and OCSP to the Intermediary CA for best practices purpose. Create the intermediate certificate Sign the csr/int.cheese.cs r with the root's certificate. We are going to drop down to /root/ca so the creation of the intermediary certificate is stored within the root's index.txt and we'll also use the root's OpenSSL Config file openssl_root.cnf . # openssl ca -config openssl_root.cnf -extensions v3_intermediate_ca -days 3600 -md sha384 -in intermediate/csr/int.cheese.csr -out intermediate/certs/int.cheese.crt.pem Using configuration from openssl_root.cnf Enter pass phrase for /root/ca/private/ca.cheese.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4097 (0x1001) Validity Not Before: Aug 24 21:51:07 2017 GMT Not After : Jul 3 21:51:07 2027 GMT Subject: countryName = US stateOrProvinceName = WA organizationName = Grilled Cheese Inc. organizationalUnitName = Grilled Cheese Intermediary CA commonName = Grilled Cheese Inc. Intermediary Certificate Authority emailAddress = grilledcheese@yummyinmytummy.us X509v3 extensions: X509v3 Subject Key Identifier: 7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Certificate is to be certified until Jul 3 21:51:07 2027 GMT (3600 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Validate the Certificate Contents with OpenSSL. # openssl x509 -noout -text -in intermediate/certs/int.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: 4097 (0x1001) Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Aug 24 21:51:07 2017 GMT Not After : Jul 3 21:51:07 2027 GMT Subject: C = US, ST = WA, O = Grilled Cheese Inc., OU = Grilled Cheese Intermediary CA, CN = Grilled Cheese Inc. Intermediary Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:9b:14:9a:55:6d:db:15:7f:d7:8b:fd:37:4d:ba: e8:50:8e:88:32:99:27:4e:20:36:25:8b:7b:ac:bb: 2f:d6:61:c1:5a:c8:e6:4c:98:20:3f:cf:86:3c:bf: f4:f3:b0:1c:1c:0b:cc:7f:e4:4b:13:59:58:a1:53: 87:cb:4c:17:66:04:21:01:6a:44:5f:22:31:7d:3d: fe:a2:e7:73:c8:77:7c:1a:f9:9c:4a:9d:e7:77:6a: c7:9e:3e:f0:4a:b0:37 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Subject Key Identifier: 7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:74:07:ba:fe:4b:71:78:d8:d2:7f:84:c0:50:b4: b6:df:6c:f6:57:f5:d9:2c:4b:e1:d4:d8:1d:78:fd:7e:bf:0a: 81:86:bb:40:c5:9b:97:6f:83:04:5f:d3:85:36:6c:d6:02:31: 00:d3:08:78:1c:da:6d:ef:1d:bb:27:df:0b:76:eb:ab:84:b2: 91:04:25:1a:85:5b:d5:c3:cd:66:e4:9e:14:b2:c0:ed:9c:59: b7:18:c3:26:eb:df:78:13:68:47:66:b5:43 Similar to the root, we can note the usage and algorithms but we have the addition of: * X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl *Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Create the certificate chain The root certificate and intermediary certificate must be available to the requesting client/server in order to validate the chain of trust. To complete the trust validation, a certificate chain must be available to the client application. A certificate chain usually takes the form of separate certificates installed into Root and Intermediary containers (as the case for Windows), or bundled together either in a .pfx cert and certchain bundle or a PEM formatted text file. Concatenate the root and intermediate certificates together to create a PEM certificate chain text file. # cd /root/ca # $cat intermediate/certs/int.cheese.crt.pem certs/ca.cheese.crt.pem > intermediate/certs/chain.cheese.crt.pem The file should look similar to this with two separate BEGIN and END statements for each certificate (example condensed for space): # cat intermediate/certs/chain.cheese.crt.pem -----BEGIN CERTIFICATE----- MIID/TCCA4OgAwIBAgICEAEwCgYIKoZIzj0EAwMwgdQxCzAJBgNVBAYTAlVTMQsw CQYDVQQIDAJXQTEQMA4GA1UEBwwHU2VhdHRsZTEcMBoGA1UECgwTR3JpbGxlZCBD ...... hkjOPQQDAwNoADBlAjB0B7r+S3F42NJ/hMBQtLbfbPZX9dksS+HU2B14/X6/CoGG u0DFm5dvgwRf04U2bNYCMQDTCHgc2m3vHbsn3wt266uEspEEJRqFW9XDzWbknhSy wO2cWbcYwybr33gTaEdmtUM= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDQTCCAsegAwIBAgIJAP+99S/FDT0CMAoGCCqGSM49BAMDMIHUMQswCQYDVQQG EwJVUzELMAkGA1UECAwCV0ExEDAOBgNVBAcMB1NlYXR0bGUxHDAaBgNVBAoME0dy ...... CgYIKoZIzj0EAwMDaAAwZQIwd6H54qs6WkvOjWouMD8Bz4523fYfA9mzXKE9bTYE +wH3MycDhd4kVhfJGuQ7NcSoAjEAzQ5s4NUm0/uIVvpnn+m+tI+UHCy3dBnO7BXS /kiTCl//67LTrlpoh9zJLFSNBGh/ -----END CERTIFICATE----- Note: In the real world hosting application should never have the entire chain available as it defeats a core principle of PKI. It's recommended in test labs to distribute the root certificate to all testing client applications and systems and include only the intermediary along with the server certificate. This way the client can establish the trust between the intermediary and root certificates. Next we'll move on to creating our CLR endpoint list and OCSP certificate. Our intermediary certificate is now created and signed and we are ready to move on. To complete the CAour next articlewe will create our certificate revocation list (CRL) endpointand online certificate status protocol (OCSP) certificate allowing us to revoke certificates. Lab environments rarely need revocation functionalitybut modern clients check for CLR and OCSP URIs so it's nessisary to have the configruation defined at minimum. Let's proceed.
AWS CloudFormation EC2 UserData example to install NGINX Plus on Ubuntu 20.04 LTS using AWS SecretsManager
Introduction There are a number of ways to automate NGINX Plus instance creation on AWS - you can create a custom AMI, or build a container image. Tools like Ansible, terraform, Pulumi etc. can also install and configure NGINX Plus. This example was tested in CloudFormation template that creates an Ubuntu 20.04 LTS EC2 instance and the uses UserData script to install NGINX Plus. A critical part of NGINX Plus install is to copy your NGINX Plus SSL Certificate and Key - required for access tothe NGINX Plus private repository - into /etc/nginx/ssl/. There a few different ways to achieve this, but the AWS SecretsManager service provides a lot of audit, access control, and security capabilities. You can use the snippets below in your AWS CloudFormation templates to retrieve the NGINX certificate and key from AWS, configure the NGINX repository on your EC2 Instance, and then download and install the software. Prerequisites Store your NGINX Plus Certificate and Key in AWS Secrets Manager - in my example I'm storing the certificate and key in separate secret objects. Create an IAM Role and policy to allow your EC2 Instance to access the secrets. My Policy looks like this: { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:ListSecretVersionIds" ], "Resource": "arn:aws:secretsmanager:*:<account ID>:secret:*" } ] } Obviously you may want to alter the the scope of the resource access. Attach this policy to a role and assign the role to your EC2 Instance in the CFT: Create a parameter (you could skip this and just add the name to the Instance Profile in the next step, but parameters can be useful if you want to change things at deploy time): NginxInstanceRole: Description: Role for instance Instance Type: String Default: EC2Secrets Reference parameter in the EC2 instance profile: NGInstanceProfile: Type: AWS::IAM::InstanceProfile Properties: InstanceProfileName: !Sub "nginx-instance-profile-${AWS::StackName}" Path: / Roles: - !Ref NginxInstanceRole Reference the instance profile in the EC2 block: # EC2 instance which will have access for http and ssh EC2Instance: Type: 'AWS::EC2::Instance' Properties: InstanceType: !Ref InstanceType SubnetId: !Ref SubnetID SecurityGroupIds: - !Ref WebSecurityGroupID - !Ref AdminSecurityGroupID KeyName: !Ref KeyPairName ImageId: !Ref InstanceImageId IamInstanceProfile: !Ref NginxInstanceRole UserData Block Now in the UserData section of your EC2 instance spec the following commands will: Install the jq package (to parse some output) Install the the AWS CLI Pull the secrets using 'aws secretsmanager get-secrets-value' Use the jq package and tr to get the files into the correct format (there may be a better way to manage this). Follow the standard NGINX plus install (add NGINX repo etc) Start the NGINX Plus service UserData: Fn::Base64: !Sub | #!/bin/bash -xe sudo apt-get update -y # good practice to update existing packages sudo apt-get install -y awscli sudo apt install -y jq sudo mkdir /etc/ssl/nginx # install the key and secret aws secretsmanager get-secret-value --secret-id nginxcert --region ${AWS::Region}| jq --raw-output '.SecretString'| tr -d '"{}'| sudo tee /etc/ssl/nginx/nginx-repo.crt aws secretsmanager get-secret-value --secret-id nginxkey --region ${AWS::Region}| jq --raw-output '.SecretString'| tr -d '"{}'| sudo tee /etc/ssl/nginx/nginx-repo.key # Add the repo sudo wget https://cs.nginx.com/static/keys/nginx_signing.key && sudo apt-key add nginx_signing.key sudo wget https://cs.nginx.com/static/keys/app-protect-security-updates.key && sudo apt-key add app-protect-security-updates.key sudo apt-get install -y apt-transport-https lsb-release ca-certificates printf "deb https://pkgs.nginx.com/plus/ubuntu `lsb_release -cs` nginx-plus\n" | sudo tee /etc/apt/sources.list.d/nginx-plus.list sudo wget -P /etc/apt/apt.conf.d https://cs.nginx.com/static/files/90pkgs-nginx # Install and start sudo apt-get update -y # good practice to update existing packages sudo apt-get install nginx-plus -y # install web server sudo systemctl start nginx.service # start webserver This should produce a working NGINX Plus install. Comment below if you'd like a complete working CFT example linked to this article.Deploy BIG-IP in AWS with HA across AZ’s - without using EIP’s
Background: The CloudFormation templates that are provided and supported by F5 are an excellent resource for customers to deploy BIG-IP VE in AWS. Along with these templates, documentation guiding your F5 deployment in AWS is an excellent resource. And of course, DevCentral articles are helpful. I recommend reading about HA topologies in AWS to start. I hope my article today can shed more light on an architecture that will suit a specific set of requirements: No Elastic IP's (EIP’s), High Availability (HA)across AZ’s, and multiple VPC’s. Requirements behind this architecture choice: I recently had a requirement to deploy BIG-IP appliances in AWS across AZ’s. I had read the official deployment guide, but I wasn’t clear on how to achieve failover without EIP’s. I was given 3 requirements: HA across AZ’s. In this architecture, we required a pair of BIG-IP devices in Active/Standby, where each device was in a different AZ. I needed to be able to fail over between devices. No EIP’s. This requirement existed because a 3 rd party firewall was already exposed to the Internet with a public IP address. That firewall would forward inbound requests to the BIG-IP VE in AWS, which in turn proxied traffic to a pair of web servers. Therefore, there was no reason to associate an EIP (a public IP address) with the BIG-IP interface. In my demo below I have not exposed a public website through a 3 rd party firewall, but to do so is a simple addition to this demo environment. Multiple VPC’s. This architecture had to allow for multiple VPC’s in AWS. There was already a “Security VPC” which contained firewalls, BIG-IP devices, and other devices, and I had to be able to use these devices for protecting applications that were across 1 or more disparate VPC’s. Meeting the requirements: HA across AZ’s This is the easiest of the requirements to meet because F5 has already provided templates to deploy these in AWS. I personally used a 2-nic device, with a BYOL license, deployed to an existing VPC, so that meant my template was this one. After this deployment is complete, you should have a pair of devices that will sync their configuration. At time of failover The supported F5 templates will deploy with the Advanced HA iApp. It is important that you configure this iApp after you have completed your AWS deployments. The iApp uses IAM permissions deployed with the template to make API calls to AWS at the time of failover. The API calls will update the route tables that you specify within the iApp wizard. Because this iApp is installed on both devices, either device can update the route in your route tables to point to its own interface. Update as of Dec 2019 This article was first written Feb 2019, and in Dec 2019 F5 released the Cloud Failover Extension (CFE), which is a cloud-agnostic, declarative way to configure failover in multiple public clouds. You can use the CFE instead of the Advanced HA iApp to achieve high availability between BIG-IP devices in cloud. Update as of Apr 2020 Your API calls will typically be sent to the public Internet endpoints for AWS EC2 API calls. Optionally, you can use AWS VPC endpoints to keep your API calls out to AWS EC2 from traversing the public Internet. My colleague Arnulfo Hernandez has written an article explaining how to do this. No EIP’s Configure an “alien IP range” I’m recycling another DevCentral solution here. You will need to choose an IP range for your VIP network that does not fall within the CIDR that is assigned to your VPC. Let’s call it an “alien range” because it “doesn’t belong” in your VPC and you couldn’t assign IP addresses from this range to your AWS ENI’s. Despite that, now create a route table within AWS that points this “alien range” to your Active BIG-IP device’s ENI (if you’re using a 2+ nic device, point it to the correct data plane NIC, not the Mgmt. interface). Don’t forget to associate the route table with specific subnets, per your design. Alternatively, you could add this route to the default VPC route table. Create a VIP on your active device Now create a VIP on your active device and configure the IP address as an IP within your alien range. Ensure the config replicates to your standby device. Ensure that source/destination checking is disabled on the ENI’s that your AWS routes are pointing to (on both Standby and Active devices). You should now have a VIP that you can target from other hosts in your VPC, provided that the route you created above is applied to the traffic destined to the VIP. Multiple VPC’s For extra credit, we’ll set up a Transit Gateway. This will allow other VPCs to route traffic to this “alien range” also, provided that the appropriate routes exist in the remote VPC’s, and also are applied to the appropriate Transit Gateway Route Table. Again, I’m recycling ideas that have already been laid out in other DevCentral posts. I won’t re-hash how to set up a transit gateway in AWS, because you can follow the linked post above. Sufficed to say, this is what you will need to set up if you want to route between multiple VPC’s using a transit gateway: 2 or more VPC’s A transit gateway in AWS Multiple transit gateway attachments that attach the transit gateway and each VPC you would like to route between. You will need one attachment per VPC. A transit gateway route table that is associated with each attachment. I will point out that you need to add a route for your “alien range” in your transit gateway route table, and in your remote VPC’s. That way, hosts in your remote VPC’s will forward traffic destined to your alien range (VIP network) to the transit gateway, and the transit gateway will forward it to your VPC, and the route you created in Step A will forward that traffic to your active BIG-IP device. Completed design: After the above configuration, you should have an environment that looks like the diagram below: Tips Internet access for deployments: When you deploy your BIG-IP devices, they will need Internet access to pull down some resources, including the iApp. So if you are deploying devices into your existing VPC, make sure you have a reachable Internet Gateway in AWS so that the devices have Internet access through both their management interface, and their data plane interface(s). Internet access for failover: Remember that an API call to AWS will still use an outbound request to the Internet. Make sure you allow the BIG-IP devices to make outbound connections over HTTPS to the Internet. If this is not available, you will find that your route tables are not updated at time of failover. (If you have a hard requirement that your devices should not have outbound access to internet, you can follow Arnulfo's guide linked to above and use VPC endpoints to keep this traffic on your local VPC) iApp logs: you can enable this in the iApp settings. I have used the logs (in /var/ltm/log) to troubleshoot issues that I have created myself. That’s how I learned not to accidentally cut off Internet access for your devices! Don’t forget about return routes if SNAT is disabled: Just like on-prem environments, if you disable SNAT, the pool member will need to route return traffic back to the BIG-IP device. You will commonly set up a default route (0.0.0.0/0) in AWS, point it at the ENI of the active BIG-IP device, and associate this route table with the subnet containing the pool members. If the pool members are in a remote VPC, you will need to create this route on the transit gw route table also. Don’t accidentally cut off internet access: When you configure the default route of 0.0.0.0/0 to point to eth1 of the BIG-IP device, don’t apply this route to every subnet in your Security VPC. It may be easy to do so accidentally, but remember that it could cause the API calls to update route tables to fail when the Standby device becomes Active. Don’t forget to disable source/dest check on your ENI’s. This is configured by the template, but if you have other devices that require it, remember to check this setting.Building an OpenSSL Certificate Authority - Creating ECC Certificates
Creating ECC Certificates Previously on Building an OpenSSL CA, we created a certificate revocation list, OCSP certificate, and updated our OpenSSL configuration file to include revokation URI data. Now we are ready to create our first server certificate and sign them with our fully armed and operational CA. What's becoming a themethere are two caveats to note prior to creating our first server CSR. Stop rolling your eyes and stay with me. Certificates MUST have subjectAltName (SAN) extensions of type DNSName defined 1 . Openssl currently supports population of SubjectAltName through configuration files only, including the current version v1.1.0f (true at guides publication date) 2 . Copy the Gist openssl_server.cnf file to /root/ca/intermediate/openssl_server.cnf and modify the contents for your own naming conventions. The openssl_server.cnf file has new entries at the [server_cert] location to create the subjectAltName field our certificate mentioned in the earlier noted points. This alternative name should matchwhat we enter for the [commonName] field. [ server_cert ] subjectAltName = @alt_names [alt_names] DNS.0 = webby.grilledcheese.us You can add additional names to the certificate by iterating the [alt_names] section. Below is an example of the openssl config formatting for multiple names. Example: [alt_names] DNS.0 = yourdomain.com DNS.1 = sassymolassy.yourdomain.com DNS.2 = *.skeletor.yourdomain.com DNS.3 = *.orco.greyskull.yourdomain.com RFC 5280regarding subject alternative names states no upper bound limit is defined (no limit to how many names you can enter). However there are practical and application limitations so plan your certificate's alternate names wisely and try to match what you would implement in production. You're also thinking, how does this scale for multiple CSRs? It doesn't. You'll need to either update the openssl_server.cnf every time you want to create a new certificate or create a copy for each new certificate. We'll worry about scripting and simplifying that process in another followup article. Create the private key and CSR. Create the private key and CSR and specify either P-256 or P-384 approved curves. Since the root and intermediary CA's use P-384, Suite B allows us to use either. If we created the CA using P-256, we would not be able to use P-384 for the client/server certificate. We also need to ensure our certificate's hash function matches the signing CA, in our case SHA-384. # cd /root/ca # openssl req -config intermediate/openssl_server.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/webby.cheese.key.pem -out intermediate/csr/webby.cheese.csr Generating an EC private key writing new private key to 'intermediate/private/webby.cheese.key.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Dev Lab]: Common Name []:webby.grilledcheese.us Email Address [grilledcheese@yummyinmytummy.us]: Create the Certificate Use the intermediary certificate to create and sign the CSR for webby.grilledcheese.us. # cd /root/ca # openssl ca -config intermediate/openssl_server.cnf -extensions server_cert -days 730 -in intermediate/csr/webby.cheese.csr -out intermediate/certs/webby.cheese.crt.pem Using configuration from intermediate/openssl_server.cnf Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4104 (0x1008) Validity Not Before: Sep 6 20:10:39 2017 GMT Not After : Sep 6 20:10:39 2019 GMT Subject: countryName = US stateOrProvinceName = WA localityName = Seattle organizationName = Grilled Cheese Inc. organizationalUnitName = Grilled Cheese Dev Lab commonName = webby.grilledcheese.us emailAddress = grilledcheese@yummyinmytummy.us X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: Grilled Cheese Generated Server Certificate X509v3 Subject Key Identifier: E0:48:57:7E:F9:92:BA:B9:F9:23:41:8D:3D:85:86:82:25:5C:FC:92 X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD DirName:/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us serial:10:01 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ X509v3 Subject Alternative Name: DNS:webby.grilledcheese.us Certificate is to be certified until Sep 6 20:10:39 2019 GMT (730 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Validate the certificate # openssl x509 -noout -text -in intermediate/certs/webby.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: 4104 (0x1008) Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, O = Grilled Cheese Inc., OU = Grilled Cheese Intermediary CA, CN = Grilled Cheese Inc. Intermediary Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Sep 6 20:10:39 2017 GMT Not After : Sep 6 20:10:39 2019 GMT Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Dev Lab, CN = webby.grilledcheese.us, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:bf:48:5b:9b:b2:e2:cf:de:e6:5a:33:3a:9f:73: 70:82:75:86:bd:6f:6a:98:e6:5e:31:fb:af:c5:9f: 68:dc:8b:bc:24:69:08:d8:35:c9:be:76:d4:3d:c5: 48:b3:8f:f6:fd:4a:b9:75:70:58:2c:65:f5:72:61: 62:b8:58:ae:ba:f1:cc:95:1e:bd:60:b2:18:92:19: d2:c3:fd:60:10:60:5a:ad:e5:29:94:f8:37:1b:5b: e5:41:50:fe:39:b9:1c ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: Grilled Cheese Generated Server Certificate X509v3 Subject Key Identifier: E0:48:57:7E:F9:92:BA:B9:F9:23:41:8D:3D:85:86:82:25:5C:FC:92 X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD DirName:/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us serial:10:01 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ X509v3 Subject Alternative Name: DNS:webby.grilledcheese.us Signature Algorithm: ecdsa-with-SHA384 30:65:02:31:00:b1:ab:4e:4f:21:86:14:12:fe:34:ea:47:00: 67:29:cb:47:70:b2:ad:22:a0:dc:5b:65:7b:22:10:5e:ea:08: 7d:09:8d:c5:77:f5:8b:ff:fa:d2:5b:7a:1e:c6:57:e2:12:02: 30:64:f1:fb:14:ea:cf:b4:20:7d:f3:f5:bc:d0:82:0c:06:03: fc:05:84:5d:f9:37:dc:d6:51:83:7b:8b:f6:91:08:d6:22:4f: 16:96:ff:0a:52:68:47:09:0c:71:90:23:d4 Validation of the webby.cheese.crt.pem file shows the updated x509 fields that define our server certificate: X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: Grilled Cheese Generated Server Certificate The certificate also includes full CRL and OCSP endpoints. X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ And it includes our required subjectAltname. X509v3 Subject Alternative Name: DNS:webby.grilledcheese.us The index.txt file we created for our intermediary certificate now has a new entry. Confirm theCA's database is updated with the newly created certificate. This file will prevent new certificates from being created with the same CN. If you need to recreate the certificate with the same name AND YOU'RE IN A LAB ENVIRONMENT, you can use vi/vim/nano/whatever to delete this line. The production-preferred method is to revoke and reissue. # cat intermediate/index.txt V 180828222314Z 1007 unknown /C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=ocsp.grilledcheese.us/emailAddress=grilledcheese@yummyinmytummy.us V 190906201039Z 1008 unknown /C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Dev Lab/CN=webby.grilledcheese.us/emailAddress=grilledcheese@yummyinmytummy.us The intermediary certificate was responsible for signing the OCSP certificate and our new server certificate; both are listed in the index.txt file. Lastly we can validate the entire certificate chain using the previously created chain.cheese.crt.pem against our newly created server certificate. # openssl verify -CAfile intermediate/certs/chain.cheese.crt.pem intermediate/certs/webby.cheese.crt.pem intermediate/certs/webby.cheese.crt.pem: OK Deploying Your Certificate Your application or server will usually accept PEM format or a PFX bundle which contains certificate, key and certificate chain (if you desire to). In production environments you would not distribute the root certificate along with the intermediate. Even in lab environments, you should distribute the root certificate independently to clients to simulate real world environments. In production systems all mainstream certificate authorities are packaged with operating systems or independent key stores. The intermediary used should match one of these existing root CAs only... For our example, if you were deploying the PEM formatted files, you would need to provide: webby.cheese.key.pem (our server certificate's private key) webby.cheese.crt.pem (our server certificate) int.cheese.crt.pem or chain.cheese.crt.pem (our intermediary CA's certificate or root and certificate concatenated into one file) If you plan to install the certificate and chain in PFX format: # openssl pkcs12 -export -out intermediate/certs/webby.cheese.pfx -inkey intermediate/private/webby.cheese.key.pem -in intermediate/certs/webby.cheese.crt.pem -certfile intermediate/certs/chain.cheese.crt.pem Enter pass phrase for intermediate/private/webby.cheese.key.pem: ****** Enter Export Password: ****** Verifying - Enter Export Password: ****** Validate the PFX bundle # openssl pkcs12 -info -in intermediate/certs/webby.cheese.pfx Enter Import Password: ****** MAC:sha1 Iteration 2048 PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Certificate bag Bag Attributes localKeyID: F7 6B 18 13 DD 04 4E 31 D7 A4 8D AE F5 1F 3B DC AD F3 F8 E8 subject=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Dev Lab/CN=webby.grilledcheese.us/emailAddress=grilledcheese@yummyinmytummy.us issuer=/C=US/ST=WA/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=Grilled Cheese Inc. Intermediary Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us -----BEGIN CERTIFICATE----- MIIFSDCCBM6gAwIBAgICEAgwCgYIKoZIzj0EAwMwgdIxCzAJBgNVBAYTAlVTMQsw .... lv8KUmhHCQxxkCPU -----END CERTIFICATE----- Certificate bag Bag Attributes: no attributes="" subject=/C=US/ST=WA/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=Grilled Cheese Inc. Intermediary Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us issuer=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us -----BEGIN CERTIFICATE----- MIID/TCCA4OgAwIBAgICEAEwCgYIKoZIzj0EAwMwgdQxCzAJBgNVBAYTAlVTMQsw .... wO2cWbcYwybr33gTaEdmtUM= -----END CERTIFICATE----- Certificate bag Bag Attributes: no attributes="" subject=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us issuer=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us -----BEGIN CERTIFICATE----- MIIDQTCCAsegAwIBAgIJAP+99S/FDT0CMAoGCCqGSM49BAMDMIHUMQswCQYDVQQG .... /kiTCl//67LTrlpoh9zJLFSNBGh/ -----END CERTIFICATE----- PKCS7 Data Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048 Bag Attributes localKeyID: F7 6B 18 13 DD 04 4E 31 D7 A4 8D AE F5 1F 3B DC AD F3 F8 E8 Key Attributes: no attributes="" Enter PEM pass phrase: Verifying - Enter PEM pass phrase: -----BEGIN ENCRYPTED PRIVATE KEY----- MIIBEzBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQItDjLLd4ozIkCAggA .... GxO/udVd0Bg0zY6eSQV1xyXhGd4GJexnKv/IHeYWjpJMyNqa4O9o -----END ENCRYPTED PRIVATE KEY----- We've completed building a two-tier NSA Suite B certificate authority for use within dev or lab environment. You'll still want to create web services to home the CRL list and act as OCSP Resolvers if you need that level of testing. The big drawback to manually using OpenSSL is the requirement of configuration files for SAN requirements. Manually updating or iterating a new OpenSSL configuration file for each certificate (requiring subjetAltName) is not efficient but I have yet to find a clean script to resolve this. I guess we'll just build one. Later. Notes: (1)The subjectAltNamefieldwas proposed to be preferredinstead of the commonName (CN) field in RFC 2818 by Mozilla's E. Rescorla (who submitted it under his company RTFM, Inc... look up the acronym). No one really knew about it because the RFC also allowed defaulting back to the CN field if no subjectAltName existed. But combined with the seldom read CA/Browser forum's Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates (released April of 2017), the subjectAltName field is now the only field of consequence for defining hostnames or IP's in a certificate. Guess how everyone found about this. Browsers simply removed support for the CN field as the host name and broke everyone's web sites siting "correcting a 17 year old requirement". Fortunately for some of us, our public CA's started auto-populating this field for a several years prior to the browser abandonment and reduced the impact to public sites. However internal CA's were left floundering (unless you read every RFC that comes out and then that doesn't even cover it). Thanks E. Rescorla for your vaugely worded RFC and Google's inability to provide visibility like they did to SHA1 deprecation (with advanced public warning and careful planning). Let's forget that the field is called ALTERNATE NAME... that annoys me at a core level. You have nothing better to do than read every RFC that could potentially affect your life, 17 years down the road... right? (2) OpenSSL Git pull request #341 "Add 'copy and 'move configuration values for DNS Subject Alternative Names" exists in the Post1.1.0 milestone but code commit is still pending into openssl:master branch. So we're stuck with config files for each certificate you want to use for now, unless you want to script it yourselves. Alternativly, OpenSSL has an GIT open Issue #3311 for "Interactivly specify subjecAltName (SAN). Here's to hoping.AWS Transit Gateway Connect: GRE + BGP = ?
GRE and BGP are technologies that are... mature. In this article we'll take a look at how you can use AWS Transit Gateway Connect to do some unique networking and application delivery in the cloud. In December 2020 AWS released a new feature of Transit Gateway (TGW) that enables a device to peer with TGW via a GRE/BGP tunnel.The intent was to be used with SD-WAN devices, but we can also use it for things like load balancing many internal private addresses, NAT gateway, etc... In this article we'll look at my experience of setting up TGW Connect in a lab environment based on F5's documentation for setting up GRE and BGP. Challenges with TGW For folks that are not familiar with TGW it is an AWS service that allows you to stitch together multiple physical and virtual networks via AWS internal networking (VPC peering) or via network protocols (VPN, Direct Connect (private L2)).Using TGW you can steer traffic to a specific network device by creating a route table entry within a VPC that points to the device's ENI (network interface).This is useful for a case where you want to send all traffic for a specific CIDR (192.0.2.0/24) to traverse that device. In the scenario where a device is responsible for a CIDR it is also responsible for updating the route table for HA.This could be done via Lambda function, our Cloud Failover Extension, manual updates, etc....The other downside is that this limits you to a single device per Availability Zone to receive traffic for that CIDR. TGW Connect provides a mechanism for the device to use a GRE tunnel/BGP to establish a connection to TGW and use dynamic routing protocols (BGP) to advertise the health of the device.This allows you to establish up to 4 devices to peer with TGW with up to 5 Gbps of traffic per connection (for comparison you can burst up to 50 Gbps with a VPC connection). Topology of TGW Connect When using TGW Connect it re-uses existing TGW connections.In practice this means that you are likely using an existing Direct Connect or VPC connection (I guess you could also use a VPN connection, but that would be weird). See also: https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-sd-wan-connectivity-with-aws-transit-gateway-connect/ Configuring a BIG-IP for TGW Connect To use a BIG-IP with TGW Connect you will need a device that is licensed for BGP (also called Advanced Routing, part of Better/Best).Follow the steps for setting up TGW Connect and be sure to specify a different peer ASN than your TGW (you will need to use eBGP).The "Peer Address" will be the self-ip of the BIG-IP on the AWS VPC (when using a VPC). Configuring target VPC When setting up TGW Connect you will peer with an existing VPC.In the subnet that you want to use with TGW Connect (Peer Address of GRE tunnel) you will need to have a route that points to the TGW peer address; for example if you specify a CIDR of 10.254.254.0/24 for TGW and the peer address is 10.254.254.11 you will need to create a route that includes 10.254.254.0/24 on the subnet for BIG-IP peer address.Also make sure to open up Security Groups to allow GRE traffic to traverse to/from the interface that will be used for the GRE tunnel.The rule should allow the IP of the peer address (i.e. 10.254.254.11). Route to TGW from 10.1.7.0/24 GRE Tunnel On the BIG-IP under Network / Tunnels you will need to create a GRE Tunnel.You can use the default "gre" tunnel profile.Specify the same "Peer Address" that youused when setting up TGW Connect. You will also want to specify the Remote Address that is the TGW address. BGP Peer Next you will need to configure the BIG-IP to act as a BGP peer to TGW connecting over the GRE tunnel.TGW requires that you use an IP in the 169.254.0.0 range.This will require modify a db variable to allow that address to be used as a self-ip.The tmsh command to use is. modify sys db config.allow.rfc3927 { value "enable" } You can then create your BGP peer address to match the value that you used in TGW Connect. The BGP peer address will need to be configured to allow BGP updates (port 179).Since the traffic is occurring over the GRE tunnel there is no need to update AWS Security Groups (invisible to the ENI). Setting up BGP Peering TGW Connect requires eBGP to be used.The following is an example of a working config.This also assumes you go through the pre-req of setting up BGP/RHI. Be careful to only advertise the routes that you want, when you use "redistribute kernel" it will also advertise 0.0.0.0/0! Please also see: https://support.f5.com/csp/article/K15923612 ! no service password-encryption ! router bgp 65520 bgp graceful-restart restart-time 120 aggregate-address 10.0.0.0/16 summary-only aggregate-address 10.1.0.0/16 summary-only aggregate-address 10.2.0.0/16 summary-only aggregate-address 10.3.0.0/16 summary-only redistribute kernel neighbor 169.254.10.2 remote-as 64512 neighbor 169.254.10.2 ebgp-multihop 2 neighbor 169.254.10.2 soft-reconfiguration inbound neighbor 169.254.10.2 prefix-list tenlist out neighbor 169.254.10.3 remote-as 64512 neighbor 169.254.10.3 ebgp-multihop 2 neighbor 169.254.10.3 soft-reconfiguration inbound neighbor 169.254.10.3 prefix-list tenlist out ! ip prefix-list tenlist seq 5 deny 10.254.254.0/24 ip prefix-list tenlist seq 10 permit 10.0.0.0/8 ge 16 ! line con 0 login line vty 0 39 login ! end This example was created with help from a BGP expert Brandon Frelich. In the example above we only limiting routes to 3 CIDRs and configuring ECMP.At this point the BIG-IP could allocate VIPs on the CIDR, act as an AFM firewall, and if we used 0.0.0.0/0 it could act as an outbound gateway. Verifying the Setup You should be able to see your BGP connection go green in the AWS console and also see the status by running "show ip bgp neighbors" from imish. AWS Console ip-10-1-1-112.ec2.internal[0]>show ip bgp summary BGP router identifier 169.254.10.1, local AS number 65520 BGP table version is 4 2 BGP AS-PATH entries 0 BGP community entries Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 169.254.10.2 4 64512 293 293 4 0 0 00:47:08 3 169.254.10.3 4 64512 293 292 4 0 0 00:47:08 3 Total number of neighbors 2 Output from imish (tmos)# list /ltm virtual-address one-line ltm virtual-address 10.0.0.0 { address 10.0.0.0 arp disabled floating disabled icmp-echo disabled mask 255.255.0.0 route-advertisement selective traffic-group none unit 0 } ltm virtual-address 10.1.0.0 { address 10.1.0.0 arp disabled floating disabled icmp-echo disabled mask 255.255.0.0 route-advertisement selective traffic-group none unit 0 } ltm virtual-address 10.2.0.0 { address 10.2.0.0 arp disabled floating disabled icmp-echo disabled mask 255.255.0.0 route-advertisement selective traffic-group none unit 0 } (tmos)# list /net route tgw net route tgw { interface /Common/tgw-connect network 10.0.0.0/8 } Output from TMSH. Note route-advertisement is enabled on the virtual-addresses. We are using a static route to steer traffic to the GRE tunnel. You should also see any routes advertised as well. ECMP Considerations When you deploy multiple BIG-IP devices TGW can use ECMP to spray traffic across multiple devices (by enabling traffic group None or multiple standalone devices). Be aware that if you need to statefully inspect traffic you may want to enable SNAT to have the return traffic go to the same device or use traffic-group-1 to run in Active/Standby via Route Health Injection. Otherwise you will need to follow the guidance on setting up a forwarding virtual server to ignore the system connection table. Routing Connections One of the issues that a customer discovered when exploring this solution is that the BIG-IP will initially send health checks across the GRE tunnel using an IP from the 169.254.x.x address range, this follows the address selection criteria that a BIG-IP uses. One method of dealing with this is to assign an IP address in a range that you would like to advertise across the tunnel like 198.168.254.0/24. Creating a self-ip of 198.168.254.253 that you assign to the tunnel. To send traffic for a different range (i.e. 10.0.0.0/16) you can then create a static route on the BIG-IP that points to 198.168.254.1. Since the BIG-IP sees the address is on the tunnel it will correctly forward the traffic through the tunnel. Another question that arose was whether it was possible to have asymmetric traffic flows of utilizing both the GRE TGW Connect tunnel and the TGW VPC Connection of the VPC itself. I discovered that YES this is possible by following the guidance on enabling asymmetrically routed traffic. It hurts your brain a bit, but here's the results of a flow that is using both a Connect and VPC connection. You can do some crazy things, but with great power... Request traffic over VPC Connection Response traffic over TGW Connect (GRE) Other Options You could also achieve a similar result by using default VPC peering and making use of Cloud Failover Extension for updating the route table.The benefit of that approach is that you don't have to deal with GRE/BGP! It does limit you to a single device per-AZ vs. being able to get up to 4 devices running across a connection.
