What Is BIG-IP?
tl;dr - BIG-IP is a collection of hardware platforms and software solutions providing services focused on security, reliability, and performance. F5's BIG-IP is a family of products covering software and hardware designed around application availability, access control, and security solutions. That's right, the BIG-IP name is interchangeable between F5's software and hardware application delivery controller and security products. This is different from BIG-IQ, a suite of management and orchestration tools, and F5 Silverline, F5's SaaS platform. When people refer to BIG-IP this can mean a single software module in BIG-IP's software family or it could mean a hardware chassis sitting in your datacenter. This can sometimes cause a lot of confusion when people say they have question about "BIG-IP" but we'll break it down here to reduce the confusion. BIG-IP Software BIG-IP software products are licensed modules that run on top of F5's Traffic Management Operation System® (TMOS). This custom operating system is an event driven operating system designed specifically to inspect network and application traffic and make real-time decisions based on the configurations you provide. The BIG-IP software can run on hardware or can run in virtualized environments. Virtualized systems provide BIG-IP software functionality where hardware implementations are unavailable, including public clouds and various managed infrastructures where rack space is a critical commodity. BIG-IP Primary Software Modules BIG-IP Local Traffic Manager (LTM) - Central to F5's full traffic proxy functionality, LTM provides the platform for creating virtual servers, performance, service, protocol, authentication, and security profiles to define and shape your application traffic. Most other modules in the BIG-IP family use LTM as a foundation for enhanced services. BIG-IP DNS - Formerly Global Traffic Manager, BIG-IP DNS provides similar security and load balancing features that LTM offers but at a global/multi-site scale. BIG-IP DNS offers services to distribute and secure DNS traffic advertising your application namespaces. BIG-IP Access Policy Manager (APM) - Provides federation, SSO, application access policies, and secure web tunneling. Allow granular access to your various applications, virtualized desktop environments, or just go full VPN tunnel. Secure Web Gateway Services (SWG) - Paired with APM, SWG enables access policy control for internet usage. You can allow, block, verify and log traffic with APM's access policies allowing flexibility around your acceptable internet and public web application use. You know.... contractors and interns shouldn't use Facebook but you're not going to be responsible why the CFO can't access their cat pics. BIG-IP Application Security Manager (ASM) - This is F5's web application firewall (WAF) solution. Traditional firewalls and layer 3 protection don't understand the complexities of many web applications. ASM allows you to tailor acceptable and expected application behavior on a per application basis . Zero day, DoS, and click fraud all rely on traditional security device's inability to protect unique application needs; ASM fills the gap between traditional firewall and tailored granular application protection. BIG-IP Advanced Firewall Manager (AFM) - AFM is designed to reduce the hardware and extra hops required when ADC's are paired with traditional firewalls. Operating at L3/L4, AFM helps protect traffic destined for your data center. Paired with ASM, you can implement protection services at L3 - L7 for a full ADC and Security solution in one box or virtual environment. BIG-IP Hardware BIG-IP hardware offers several types of purpose-built custom solutions, all designed in-house by our fantastic engineers; no white boxes here. BIG-IP hardware is offered via series releases, each offering improvements for performance and features determined by customer requirements. These may include increased port capacity, traffic throughput, CPU performance, FPGA feature functionality for hardware-based scalability, and virtualization capabilities. There are two primary variations of BIG-IP hardware, single chassis design, or VIPRION modular designs. Each offer unique advantages for internal and collocated infrastructures. Updates in processor architecture, FPGA, and interface performance gains are common so we recommend referring to F5's hardware pagefor more information.Using Client Subnet in DNS Requests
BIG-IP DNS 14.0 now supports edns-client-subnet (ECS) for both responding to client requests (GSLB) or forwarding client requests (screening). The following is a quick start on using this feature. What is EDNS-Client-Subnet (ECS) If you are familiar with X-Forwarded-For headers in HTTP requests,ECS solves a similar problem. The problem is how to forward a DNS request through a proxy and preserve information about the original request (IP Address). Some of this discussion I also cover in a previous article,Implementing Client Subnet in DNS Requests . Traditional DNS Requests When a traditional DNS request is made, a client makes a request to a “local” DNS server (LDNS), and that request is forwarded to the authoritative DNS server for that domain. When a topology (send different responses based on the source address) record is evaluated it will use the source IP of the LDNS server. Usually this is OK for most applications, but it would be ideal to be able to forward more precise information from the LDNS server. ECS DNS Requests Using ECS a LDNS server can inject additional meta-data about the request that includes information about the source IP address of the client. In the following example a “Client Subnet” of 192.0.2.0/24 is forwarded to the DNS server. ECS on BIG-IP DNS F5 BIG-IP DNS can use ECS in two ways. Use ECS when handling topology requests Inject ECS when “screening” a DNS server Using ECS with BIG-IP DNS Topology There are two methods of configuring BIG-IP DNS to use ECS. Either at the wide-ip or globally. To configure ECS on a wide-ip: To configure ECS globally. Under DNS Settings. Injecting ECS records BIG-IP DNS can also proxy requests to other DNS servers (BIG-IP DNS or other vendors). When you modify the DNS profile to insert an ECS record. You will observe that the original /32 address will be forwarded to any DNS servers that are in the pool for that particular Virtual Server. The following is a diagram of the above.DNS Express and Zone Transfers
This is the third in a series of DNS articles that I'm writing. The first two are: Let's Talk DNS on DevCentral DNS The F5 Way: A Paradigm Shift DNS Express is a relatively new feature (showed up in v11.1), and it's one of the more powerful features offered by the BIG-IP. DNS Express allows you to transfer DNS zones from your current infrastructure to the BIG-IP. The BIG-IP can then answer requests for those zones...and do it at blazingly fast speeds! Another benefit of DNS Express is that it doesn't run full BIND, so it's not as vulnerable as a typical BIND infrastructure. Related note: as of the date of this article, BIND alone had 71 different CVE vulnerabilities (41 of those were DoS-specific). With all this greatness at our fingertips, I want to show you how to provision the Global Traffic Manager (GTM), create a zone, configure DNS Express, and show a successful zone transfer. I'll be using BIND from the GTM as the Master server (disclaimer: I'm doing this in my virtual lab setup, but you wouldn't normally do this in a production environment). Provision GTM First, navigate to System >> Resource Provisioning and check the box for Global Traffic (GTM). Make sure that this module is licensed (keep in mind that you will have to restart your BIG-IP once you provision GTM). See the screenshot below for details. If GTM is not licensed, then talk to your Sales Engineer. By the way, you can take advantage of our new Good, Better, Best licensing model and save yourself time and money. If you get the "Best" option, then you basically get all the modules F5 has to offer! Create a Listener Once GTM is provisioned, it's time to create a listener for the DNS requests (navigate to Global Traffic >> Listeners). I used the address from my external VLAN as the listener address, but in a production environment you would choose a different listener address. When creating a Listener, you need to choose a DNS Profile that has DNS Express enabled. I verified that DNS Express was enabled on the profile listed below (dns). You can enable/disable options like IPv6 to IPv4 translation, DNS Express, DNSSEC, etc in the DNS profile. So, make sure you configure your DNS profile correctly prior to selecting it when creating a Listener. Configure ZoneRunner Now that the listener is created and configured, you can use the ZoneRunner utility to manage your DNS zones and resource records. You can do several things with ZoneRunner including: configuring a zone configuring the resource records that make up that zone configure a view for access control configure options in the named.conf file I created a master zone and named it "dnstest.com" and then configured the SOA Record and NS Record details (TTL values, server names, etc). I also created two A records (www.dnstest.com and ftp.dnstest.com) and associated IP addresses with each. You can see the details of the zone in the screenshot below: After I created the zone, I configured the Named Configuration file to allow for zone transfer from the local host. You can view/modify the named.conf file directly from the GUI by navigating to Global Traffic >> ZoneRunner >> Named Configuration. The named configuration file will also automatically update as you make changes in the other areas of the ZoneRunner utility, so you don't always have to configure it directly. In my case, I simply viewed the file to ensure the "allow-transfer localhost" was there...and it was! This entry was required for the BIND server to transfer the zone information for dnstest.com to the DNS Express module. In my lab setup, I used BIND from GTM as the Master server, but in a production environment, the Master BIND server would probably reside on an external server. In a typical setup where you host zones external to the BIG-IP, you would have to add the following code to the zone file. In my case, I didn't have to add this code because I set up everything on the BIG-IP. zone "dnstest.com" { type master; file "var/lib/bind/dnstest.com.hosts"; also-notify {1.1.1.1;}; //where 1.1.1.1 is the listener address allow-transfer {1.1.1.2;}; //where 1.1.1.2 is the self IP }; DNS Express DNS Express provides the ability for a BIG-IP to act as a high speed, authoritative secondary DNS server. This allows the BIG-IP to perform zone transfers from multiple primary DNS servers that are responsible for different zones, perform a zone transfer from the local BIND server on the BIG-IP, and serve DNS records faster than the primary DNS servers and the local BIND server. To use DNS Express, you need to create a DNS Express zone. Then, you can transfer zone records from the local BIND server or back-end DNS servers to DNS Express. In order to set up a DNS Express Zone, navigate to Local Traffic >> DNS Express Zones >> DNS Express Zone List and create a new zone. Note that DNS Express is configured under "Local Traffic" as part of the Local Traffic Manager (LTM). The best practice is to use the name that appears at the apex of a BIND zone file (in my case, dnstest.com). The name must begin with a letter and can contain only letters, numbers, and the underscore character (it doesn't have to contain each of these, but it can't contain anything other than these characters). The Target IP Address is for the DNS server from which you want to transfer records. In my setup, I used the default value (127.0.0.1) which is for the BIND server on the BIG-IP. The Notify Action setting of "consume" means that NOTIFY queries are only seen by DNS Express...you can think of it like DNS Express "consumes" all the NOTIFY queries and the backend DNS resources never have to handle them. This is the default setting...and it's awesome! The Test... After everything had been configured, the zone records should have been transferred to DNS Express. In order to test this, I used the "dnsxdump" command from the CLI to verify that all the records were in the DNS Express database. As you can see in the screenshot below, all the records transferred correctly! In addition, I checked out /var/log/ltm to look for the zone transfer message. As you can see in the screenshot below, the zone transfer (AXFR Transfer of zone dnstest.com) succeeded! Now that you know how to configure DNS Express, you have no reason to not use it...so get out there, get it configured, and let the BIG-IP provide you with the best DNS performance you've ever experienced! I also created a quick video showing how to do all the things I just wrote about in this article (provision GTM, create a listener, create a zone, etc). So, if you're more of a "hands-on, visual learner" check out the video...it's located here: https://devcentral.f5.com/s/videos/dns-express-and-zone-transfers Well, that wraps it up for this article. I'll be back soon with more BIG-IP and GTM articles, so check back often!
Add multiple entries for TXT record in BIND
Hello Folks, I have an existing TXT record for my domain abc.com. As per our security team we have to add an extra token to the TXT record to inform that we actually own the domain. Unsure how to add it. Should i create a new record or can it be appended to existing record. Please advise. Eg : Existing record : "v=spf1 a mx ptr ip4:65.49.39.200/29" , new string : DZC=DlaVBmG Regards, AnoopWhat is BIG-IP DNS?
tl;dr - BIG-IP DNS provides global load balancing (GSLB), DNS services, and basic DDoS protection features. By now we all understand the concepts behind load balancing; creating a virtual access point to distribute traffic across multiple resources. Keeping that idea in mind the next question is how do we advertise our application available across separate data centers? BIG-IP DNS (formerly Global Traffic Manager or GTM) first and foremost is a global load balancer for DNS queries. Using similar algorithms for load balancing decision made by BIG-IP Local Traffic Manager (LTM), BIG-IP DNS routes your DNS traffic to the best suited datacenter either on premise, co-located, or in your preferred cloud provider. BIG-IP DNS also provides DNS resolution services, including caching and traffic throttling to ensure queries made about your applications are always answered and fast. Vocabulary To understand BIG-IP DNS, we'll first define a few product terms. Wide IP - Owns your services FQDN and responds to listener requests. The Wide IP contains one or more pools which in turn contain one or more virtual servers. Server - In this case, the server defined in BIG-IP DNS is either a BIG-IP or other 3rd party system responsible for owning one or more virtual server service. GSLB - Global Server Load Balancing. The GSLB section within BIG-IP DNS configuration is the core of intelligent DNS resolution services. Listener - BIG-IP uses TCP/UDP listeners to respond to DNS queries. Pool - In BIG-IP DNS a pool contains one or more virtual servers. How BIG-IP DNS Works BIG-IP DNS has grown over the years to incorporate many new features, but we'll stick to discussing the core global server load balancing (GSLB) functionality. Let's first take a look at a traditional DNS query (we're assuming no system has example cached): Client queries www.example.com to local DNS (LDNS) LDNS queries ROOT Servers ROOT Servers send the query to the .com TLD server TLD Servers provide the name server IP for example.com to LDNS server (glue records if you got em) example.com name servers lookup www entry and send to LDNS request LDNS Server returns IP for www.example.com to client Client is now browsing. BIG-IP DNS enters the picture at step 5 and adds a few extra steps: BIG-IP DNS Listener receives the query for example.com The Wide-IP associated to example.com makes a load balancing decision on what pool to send the request to The chosen pool makes a secondary load balancing decision on what virtual server to send the request to The virtual server IP is returned to the originating LDNS server Client is more happy because they were routed to a regionally located server with faster response times. In this scenario, the BIG-IP DNS provided a faster application experience for the user by determining the region the user resided and provided the fastest performing server's as the IP for the FQDN requested by DNS. BIG-IP DNS provides more features to enhance the GSLB features including accelerating DNS resolution and acting as a fast secondary DNS server. Below you can learn more about BIG-IP DNS and as always if you have questions or commentplease let us know. DevCentral Basics - What is DNS? Lightboard Lessons: BIG-IP DNS Load Balancing Intro Lightboard Lessons: DNS Scalability & Security Getting Started with BIG-IP DNS (formerly GTM) @F5 University
web proxy XFF header https
Hello, I have recently noticed that my configured F5 proxy is forwarding XFF for http but not for https. For https the F5 is being the broker for client and so client source becomes the F5 for https. Is there any way for the F5 to proxy client WWW traffic and forward XFF? We are running identity awareness on the next hop device. flow is as follows. (F5 VS is explicit http proxy currently) client --> GTM pool to resolve client proxy IP --> GSLB pool (3 x VS) --> Check point with IA (3 in total) In F5 case, the next hop and DG is the Check Point firewall. If the above cannot send XFF for https: is there another way to use the F5 as a WWW proxy and send original client IP or information to the next hop Check Point? if we enabled WWW proxy on the Check Point, can the GTM resolve to the Check Point as a node without proxying the users? There are three routes to the internet for clients Thanks for any help, Derrick
BIG-IP Edge client disconnects after authentication and Finalizing then disconnected again
My BIG-IP Edge client on windows 10 has not been able to connect me on this my laptop for 3 weeks now. It was working before but all of sudden stop working. But with same login details i can connect in other laptops except this mine. I can't figure out what has changed and i have not installed anything since that time. Below is the error where it is failing: Error 2018-01-26 6:38:21:715 HOST \HostCtrl.h, CHostCtrl::~CHostCtrl(), stopServer() COM call failed, -2147352567 . . . Error 2018-01-26 6:38:22:721 HOST \proxy.cpp, CHostCtrl::ProxyClose(), Close() failed, -2147352567
Configuring the F5 BIG-IP to Perform Name Resolution Using a DNS Resolver Cache
After feedback on both DevCentral and direct email, it seems as though there is still confusion or a lack of clarity around how to configure the BIG-IP to perform name resolution. A common scenario of my own customers is to configure the BIG-IP as an authoritative DNS server as well as a transparent DNS server that forwards lookups to another source. With that, I wanted to take some time to walk through the steps of configuring the BIG-IP to be a resolving cache DNS server. However, before we get started I wanted to provide the F5 support definition of each cache type provided by the BIG-IP. About the transparent DNS cache You can configure a transparent cache on the BIG-IP® system to use external DNS resolvers to resolve queries, and then cache the responses from the resolvers. The next time the system receives a query for a response that exists in the cache, the system immediately returns the response from the cache. The transparent cache contains messages and resource records. About the resolver DNS cache You can configure a resolver cache on the BIG-IP® system to resolve DNS queries and cache the responses. The next time the system receives a query for a response that exists in the cache, the system returns the response from the cache. The resolver cache contains messages, resource records, and the name servers the system queries to resolve DNS queries. About the validating resolver DNS cache You can configure a validating resolver cache on the BIG-IP® system to recursively query public DNS servers, validate the identity of the DNS server sending the responses, and then cache the responses. The next time the system receives a query for a response that exists in the cache, the system returns the DNSSEC-compliant response from the cache. The validating resolver cache contains messages, resource records, the nameservers the system queries to resolve DNS queries, and DNSSEC keys. Ok, now with that out of the way, let's get started! Prerequisites BIG-IP DNS licensed and provisioned. An external internet route. Create a Resolver Cache Navigate to DNS >> Caches >> Cache List. Click Create. Name: demo_resolver_cache Resolver Type: Resolver Click Finished Note: If Root Hints is left default it will use the F5 defined default root hints. If this is an air-gapped or classified network, you will need to define your network's root hint servers. Also if you plan to use only root hints, you may experience some timeouts during name resolution. To improve name resolution, we will create a Forward Zone which allows us to define another authoritative source to do lookups against. Click the cache created in the previous steps. Click the Forward Zones tab. Click Add. Name: . Nameservers: 8.8.8.8 & 9.9.9.9 Click Finished. Create a DNS Profile Navigate to DNS >> Delivery >> Profiles >> DNS. Click Create. Name: demo_dns_profile DNS Cache: Enabled DNS Cache Name: demo_resolver_cache Use BIND Server on BIG-IP: Disabled Click Finished. Create a DNS Listener Navigate to DNS >> Delivery >> Listeners >> Listener List. Click Create. Name: demo_dns_listener Destination: 10.1.20.153 Source Address Translation: Auto Map DNS Profile: demo_dns_profile Click Finished. Validate Successful Name Resolution Navigate to a workstation that will be using the BIG-IP to resolve queries. Launch a command prompt. Type nslookup. Type server 10.1.20.153 Attempt to query external domain names. (e.g. nfl.com, nba.com, nhl.com, abcmouse.com) From the BIG-IP itself, you can also run a dig which is an extremely useful tool. Validate Cache Launch a ssh session to your BIG-IP using putty or the client of your choice. Run the following command. tmsh show ltm dns cache records rrset cache demo_resolver_cache You have now successfully configured your BIG-IP instance to perform name resolution as a recursive DNS server as well as cache DNS responses for faster name resolution. I really hope between this article and others it helps clarify some of the questions out there regarding recursive and authoritative DNS capabilities the BIG-IP provides.
BIG-IP DNS Resource Record Types: Architecture, Design and Configuration
Welcome to my first article on DevCentral! This article starts aseries about BIG-IP DNS (the artist formerly known as GTM). This article and accompanying videos take a look at the support for Domain Name System (DNS) Resource Record (RR) types that were introduced in BIG-IP version 12.0. This enhancement represented a major step forward in the capabilities available on the BIG-IP. I created these videos during the initial introduction of the feature in BIG-IP 12.0 release. Based on the timestamp in the BIG-IP GUI, that would be October of 2015. The information presented here is still relevant for later versions of BIG-IP and will be of benefit to anyone trying to understand the different DNS resource record types available on the BIG-IP. The videos assume you have used BIG-IP DNS before, and you understand the basics of DNS. If you need a refresher on DNS resource records, I present an overview of the new and existing resource records supported by BIG-IP DNS. I then go into the feature itself and the architecture and implementation details for each of the records on BIG-IP DNS. In the last video, I do a configuration walk-through of a NAPTR and SRV wideIP along with the NAPTR and SRV pools. Be sure and see the attachment at the end of the article. It is a zip file that contains a PDF of many of the slides I use in the videos. Executive Summary (9 Minutes) First up is the Executive Summary. This video introduces, at a high level, everything that will be covered in the later videos. It also talks about some things that are not explicitly called out in any of the other content. Technology Overview (8 Minutes) Next is a DNS technology overview for the different resource record types supported by BIG-IP DNS. If you are already familiar with the different DNS RR types (A, AAAA, CNAME, NAPTR, SRV, MX), you can skip this part. If you need a quick refresher on what each record type is and the fields used in them this content is for you! NOTE: This is not a discussion of how the BIG-IP DNS implements these resource records but rather a discussion of the record types themselves in a purely DNS sense. Feature/Architecture Overview If you do not watch any of the other videos in this series, watch these!! I go over the concepts and architecture behind how the different resource records are implemented and configured on BIG-IP DNS with lots of diagrams. The configurations of the different resource record types and all the associated pools can get confusing. These videos will give you a solid foundation to follow the configuration walk-through. I am going to be bold here and say that I guarantee you will learn something you did not know about BIG-IP DNS if you watch the next five videos. As a polling mechanism, hit the “Like” button on the article if I was correct in my prediction. General Information and A/AAAA Records (11:30 Minutes) This video covers general information about the DNS RR implementation along with the A and AAAA record types. For example, the video talks about a new concept in BIG-IP DNS called Non-Terminal and Terminal Pools and what they mean in wideIP configurations. CNAMEs (9 Minutes) This is a long discussion about CNAMEs. Who knew they were so interesting? Well, they are, and it is worth listening to how they are implemented on BIG-IP DNS. NAPTR, SRV and MX Records (5:30 Minutes) NAPTR, SRV and MX records are next. The configuration walk-through later in this article will implement NAPTR and SRV wideIPs. Health Checks (7:30 Minutes) Let’s talk about one of the reasons you have a BIG-IP DNS…health checks! Now that wideIPs can be pool member, the game has changed. Persistence (8 Minutes) Persistence also has some new wrinkles. If you use persistence, you want to watch this. Configuration Walk-through (11:30 Minutes) Finally, we have the configuration walk-through. This is where things get real. In this video, I do a configuration of NAPTR and SRV wideIPs along with the NAPTR and SRV pools. You can see the configuration objects I will create and the order in the diagram below. Conclusion That is all I have for this article. I hope you learned something and most importantly have a better understanding of the different DNS resource record types available on the BIG-IP DNS. I have more articles and videos to come so stay tuned. Be sure and grab the attachment if you want a copy of some of the diagrams used in the videos. Trivia: iQuery uses port 4353 for its communication. Do you know the significance/meaning of that particular port number? Drop a comment at the bottom if you know the answer.
