F5 LTM SNAT: only 1 outgoing connection, multiple internal clients
I have an F5 LTM SNAT configured: ltm snat /Common/outgoing_snat_v6 { description "IPv6 SNAT translation" mirror enabled origins { ::/0 { } } snatpool /Common/outgoing_snatpool_v6 vlans { /Common/internal } vlans-enabled } ... with a translation configured as: ltm snat-translation /Common/ext_SNAT_v6 { address 2607:f160:c:301d::63 inherited-traffic-group true traffic-group /Common/traffic-group-1 } ... with snatpool configured as: ltm snatpool /Common/outgoing_snatpool_v6 { members { /Common/ext_SNAT_v6 } } ... and finally, with the SNAT type set to automap: vs_pool__snat_type { value automap } The goal is to achieve a single Diameter connection (single source IP, port) between F5 and the external element, while internally multiple Diameter clients connect via F5 to the external element: However, what ends up happening with this SNAT configuration is that multiple outgoing Diameter connections to the external Diameter element are opened, with the only difference between them being the source port (source IP, destination IP and port remained the same). The external element cannot handle multiple connections per the same origin IP and the same Diameter entity (internal clients are all configured to use the same Origin-Host during the Capabilities Exchange phase). Is there a way to configure F5 to funnel all the internal connections into a single outgoing one?
Create IPv6 self-IP with Route Domains on 10.2.3
We need to create IPv6 self-IPs in a non-default Route Domain, but we are getting the following error: The vlan () for the specified self IP () must be one of the vlans in the associated route domain (0). Seems the internal F5 logic interpret this as an IP-address from Route Domain 0, although we are in a partition which is mapped to Route Domain 4 (doing this, you normally don't need to append the <%RD>). I verified this also on version 11.x and there it's not an issue. So is this a bug in version 10.2.3 or do I need to use a special format? Or isn't this kind of setup supported in such an old version? Thank you! Ciao Stefan 🙂
How to check if a string parameter can be an IPv4 or an IPv6 or nothing in an iRule ?
How to deal with that question in the best optimized way to code it versus cycles ? "How to check if a string parameter can be an IPv4 or an IPv6 or nothing in an iRule ?" I have already looked at "IP::addr .... mask ...scan ..." without any simple efficient way. Some helps ? Some few lines ? or TCL function or undocumentated iRule command ? Many thanks :-)
Reverse records (PTR) for IPv6
Hi folks, i got an F5 DNS acting as a nameserver, ready for ipv6, but now we got the create the reverse records (PTR) for the clients subnet, and those subnet are millions of millions of addreses, so millions of records, i dont know how we can solve this, with an irule i guess or maybe you guys know another method working somewhere. Thanks guys!
NAT IPv6 to IPv6 (NAT66)
Hi, I have a scenario which requires us to do ipv6 to ipv6 natting. (map a private-ipv6 to a public-ipv6) We are using the soft version 13.1.1.4 and it seems it doesn't properly work. We tried the following: 1. cfged a snat pool list w/ one ipv6 address, next this snat was assigned to our ipv6 virtual-server. tshooting it w/ tcpdump shows no translation occurs. i found under the 14.x release notes a bug ID681070 whichseems similar "NAT66 may fail if configured with a single translation address". we then tried to cfg the snat pool list w/ an ipv6/124 prefix resultingin errors by the f5 saying " 01020059:3: IP Address :: is invalid, must not be all zeros." tried using an iRULE w/ plain when client_accepted, snat ipv6address... this didn't work either, we receiving TCL errors bad IP address format (line 1)TCL error (line 1) (line 1) invoked from within "snat xxxx:6xx0:0001:0100:00xx:0xx5:0104:0/124" Did anyone successfully configure something like this? Any ideas will be very much appreciated. thanks,Is it cmpulsory to enable DNS IPv6 to IPv4 to host IPv6 listner?
Comment made 1 day ago by Mihir Joshi 2 Hi, I have a question. Is it compulsory to enable option "DNS IPv6 to IPv4" if we host IPv6 listener on BIG-IP DNS (GTM)? We are experiencing strange issue. User belong to one of the Europe region not able to connect application when they connect from their home Wi-Fi which have IPv6 addresses enabled. On GTM we have IPv6 listener and IPv4 listener which shares same DNS profile which enabled with option "DNS IPv6 to IPv4" (Secondary). Because of this end user receives two records in IPv6 addresses in format of "::xxx.xxx.xxx.xxx". Do you think this could be a reason for issue we are currently experiencing? When we ask client to change their IP schema from IPv6 to IPv4 it works perfectly fine. Regards, MihirDNS on the BIG-IP: IPv6 to IPv4 Translation
I've been writing some DNS articles over the past couple of months, and I wanted to keep the momentum going with a discussion on IPv6 translation. As a reminder, my first four articles are: Let's Talk DNS on DevCentral DNS The F5 Way: A Paradigm Shift DNS Express and Zone Transfers The BIG-IP GTM: Configuring DNSSEC The Address Space Problem I'm pretty sure all of you have heard about the problem of IPv4 address depletion, so I won't go too crazy on that. But, I did want to share one quick analogy of how the IPv4 address space relates to the IPv6 space. There are ~4 billion possible IPv4 addresses and ~3.4 x 10 38 IPv6 addresses. Sometimes when I see a comparison of large numbers like these, it's hard for me to grasp the magnitude of the difference. Here's the analogy that helped put this in perspective: if the entire IPv4 address space was a single drop of water, the IPv6 address space would be the equivalent of 68 times the entire volume of the world's oceans! I can't imagine ever needing more IP address space than that, but I guess we will see. As IPv4 address space is used up and new IP-enabled devices continue to hit the market, companies need to support and manage existing IPv4 devices and content while transitioning to IPv6. Just last week, ICANN announced that IPv4 addresses are nearing total exhaustion. Leo Vegoda, operational excellence manager at ICANN, said "Redistributing increasingly small blocks of IPv4 address space is not a sustainable way to grow the Internet. IPv6 deployment is a requirement for any network that needs to survive." As companies transition to IPv6, they still face a real issue of handling IPv4 traffic. Despite the need to move to IPv6, the fact is most Internet traffic today is still IPv4. Google has a really cool graph that tracks IPv6 adoption, and they currently report that only 3.5% of all Internet traffic is IPv6. You would think that the people who developed IPv6 would have made it backward compatible with IPv4 thus making the transition fairly easy and straightforward...but that's not true. This leaves companies in a tough spot. They need a services fabric that is flexible enough to handle both IPv4 and IPv6 at the same time. The good news is that the BIG-IP is the best in the business at doing just that. BIG-IP Configuration Let's say you built an IPv6 network and things are running smoothly within your own network...IPv6 talking to IPv6 and all is well. But remember that statistic I mentioned about most of the Internet traffic running IPv4? That creates a big need for your network to translate from IPv6 to IPv4 and back again. The BIG-IP can do this by configuring a DNS profile and assigning it to a virtual server. You can create this DNS profile by navigating to Local Traffic >> Profiles >> Services >> DNS and create/modify a DNS profile. There are several options to configure in the DNS profile, but for this article, we are just going to look at the DNS IPv6 to IPv4 translation part. Notice the three DNS IPv6 to IPv4 settings in the screenshot below: DNS IPv6 to IPv4, IPv6 to IPv4 Prefix, and IPv6 to IPv4 Additional Section Rewrite. The DNS IPv6 to IPv4 setting has four options. This setting specifies whether you want the BIG-IP to convert IPv6-formatted IP addresses to IPv4-formatted IP addresses. The options for DNS IPv6 to IPv4 are: Disabled: The BIG-IP does not map IPv4 addresses to IPv6 addresses. This is the default setting. Secondary: The BIG-IP receives an AAAA (IPv6) query and forwards the query to a DNS server. Only if the server fails to return a response does the BIG-IP system send an A (IPv4) query. If the BIG-IP system receives an A response, it prepends a 96-bit user-configured prefix to the record and forwards it to the client. Immediate: The BIG-IP system receives an AAAA query and forwards the query to a DNS server. The BIG-IP then forwards the first good response from the DNS server to the client. If the system receives an A response first, it prepends a 96-bit prefix to the record and forwards it to the client. If the system receives an AAAA response first, it simply forwards the response to the client. The system disregards the subsequent response from the DNS server. v4 Only: The BIG-IP receives an AAAA query, but forwards an A query to a DNS server. After receiving an A response from the server, the BIG-IP system prepends a 96-bit user-configured prefix to the record and forwards it to the client. Only select the v4 Only option if you know that all DNS servers are IPv4-only servers. When you select one of the options listed above (except the "Disabled" option), you must also provide a prefix in the IPv6 to IPv4 Prefix field and make a selection from the IPv6 to IPv4 Additional Section Rewrite list. The IPv6 to IPv4 Prefix specifies the prefix to use for the IPv6-formatted IP addresses that the BIG-IP converts to IPv4-formatted IP addresses. The default is 0:0:0:0:0:0:0:0. The IPv6 to IPv4 Additional Section Rewrite allows improved network efficiency for both Unicast and Multicast DNS-SD responses. This setting has 4 options: Disabled: The BIG-IP does not perform additional rewrite. This is the default setting. V4 Only: The BIG-IP accepts only A records. The system prepends the 96-bit user-configured prefix (mentioned previously) to a record and returns an IPv6 response to the client. V6 Only: The BIG-IP accepts only AAAA records and returns an IPv6 response to the client. Any: The BIG-IP accepts and returns both A and AAAA records. If the DNS server returns an A record in the Additional section of a DNS message, the BIG-IP prepends the 96-bit user-configured prefix to the record and returns an IPv6 response to the client. Like any configuration change, I would recommend initial testing in a lab to see how your network performs with these settings. This one is pretty straightforward, though. Hopefully this helps with any hesitation you may have with transitioning to an IPv6 network. Go ahead and take advantage of that vast IPv6 space, and let the BIG-IP take care of all the translation work! Stay tuned for more DNS articles, and let me know if you have any specific topics you'd like to see. One final and related note: check out the F5 CGNAT products page to learn more about seamless migration to IPv6.
F5 Friday: The Low Down on BIG-IP and VMware Stuff
#vmworld #vCloud #PHC6050 #EUC6104 #sddc How-tos and where to learn more about what's new with F5 and VMware As we're all gearing for up VMWorld (you are gearing up for the event, right?) it seems appropriate to highlight some existing resources for implementing VMware solutions with F5 BIG-IP and let you know where you can find out more at the show (hint: there are going to be sessions and a demo of a new joint solution!) So first, let's check out some recently posted how-tos from VMware folks on configuring BIG-IP and VMware solutions: First up is a great post on using F5 BIG-IP with Horizon Workspace 1.5 to load balance gateway-VAs for both internal and external access as well as load balancing Kerberos enabled connector VAs. You can download the document here: https://communities.vmware.com/docs/DOC-24577 If you're attending VMWorld, you can also attend a session on how to make Horizon View More Secure, Available, Scalable and Usable with F5 (EUC6104) presented by F5's own Paul Pindell Monday, Aug 26, 11:30 AM - 12:30 PM in Moscone West, Room 2005. Next up is configuring F5 BIG-IP LTM with VMware vCloud Director. This post appears to be the only one available that details how to setup the vCD Console Proxy via F5 BIG-IP. This is an important step that's often overlooked in other how-tos, so you'll want to check it out. Finally, here's a great post on using F5 BIG-IP LTM with IPv6. The noise around IPv6 has dulled to a quiet roar but it's still an increasingly important protocol to understand and using F5 is an awesome and quick way to enable legacy web applications for IPv6. How's that relate to VMware? Well, once you complete the configuration it will make the web interface of vCD available via IPv6. Finally, if you're attending the show, you'll want to attend a session presented by F5's own Charlie Cano and VMware Senior Product Manager, Dan Mitchell, on Monday, Aug 26, 3:30 PM - 4:30 PM in Moscone West, Room 3008 on the topic of Moving Beyond Infrastructure: Meeting Demands on App Lifecycle Management in the Dynamic Datacenter (PCH6050). This session is going to dig into some of the details behind the latest joint solution from F5 and VMware, taking the next step toward a Software-Defined Data Center. The solution is based on a new offering being launched by VMware at the show Monday and F5 will be providing a demo at its booth at the show of the joint solution. You don't want to miss it. If you aren't attending the show or can't make the sessions, be sure to check back here Monday for details on the new joint solution.DNS Architecture in the 21st Century
It is amazing if you stop and think about it, how much we utilize DNS services, and how little we think about them. Every organization out there is running DNS, and yet there is not a ton of traction in making certain your DNS implementation is the best it can be. Oh sure, we set up a redundant pair of DNS servers, and some of us (though certainly not all of us) have patched BIND to avoid major vulnerabilities. But have you really looked at how DNS is configured and what you’ll need to keep your DNS moving along? If you’re looking close at IPv6 or DNSSEC, chances are that you have. If you’re not looking into either of these, you probably aren’t even aware that ISC – the non-profit responsible for BIND – is working on a new version. Or that great companies like Infoblox (fair disclosure, they’re an F5 partner) are out there trying to make DNS more manageable. With the move toward cloud computing and the need to keep multiple cloud providers available (generally so your app doesn’t go offline when a cloud provider does, but at a minimum for a negotiation tool), and the increasingly virtualized nature of our application deployments, DNS is taking on a new importance. In particular, distributed DNS is taking on a new importance. What a company with three datacenters and two cloud providers must do today, only ISPs and a few very large organizations did ten years ago. And that complexity shows no signs of slacking. While the technology that is required to operate in a multiple datacenter (whether those datacenters are in the cloud or on your premise) environment is available today, as I alluded to above, most of us haven’t been paying attention. No surprise with the number of other issues on our plates, eh? So here’s a quick little primer to give you some ideas to start with when you realize you need to change your DNS architecture. It is not all-inclusive, the point is to give you ideas you can pursue to get started, not teach you all that some of the experts I spent part of last week with could offer. In a massively distributed environment, DNS will have to direct users to the correct location – which may not be static (Lori tells me the term for this is “hyper-hybrid”) In a IPv6/IPv4 world, DNS will have to serve up both types of addresses, depending upon the requestor Increasingly, DNSSEC will be a requirement to play in the global naming game. While most orgs will go there with dragging feet, they will still go The failure of a cloud, or removal of a cloud from the list of options for an app (as elasticity contracts) will require dynamic changes in DNS. Addition will follow the same rules Multiple DNS servers in multiple locations will have to remain synched to cover a single domain. So the question is where do you begin if you’re like so many people and vaguely looked into DNSSEC or DNS for IPv6, but haven’t really stayed up on the topic. That’s a good question. I was lucky enough to get two days worth of firehose from a ton of experts – from developers to engineers configuring modern DNS and even a couple of project managers on DNS projects. I’ll try to distill some of that data out for you. Where it is clearer to use a concrete example or specific terminology, as almost always that example will be of my employer or a partner. From my perspective it is best to stick to examples I know best, and from yours, simply call your vendor and ask if they have similar functionality. Massively distributed is tough if you are coming from a traditional DNS environment, because DNS alone doesn’t do it. DNS load balancing helps, but so does the concept of a Wide IP. That’s an IP that is flexible on the back end, but static on the front end. Just like when load balancing you have a single IP that directs users to multiple servers, a Wide IP is a single IP address that directs people to multiple locations. A Wide IP is a nice abstraction to actively load balance not just between servers but between sites. It also allows DNS to be simplified when dealing with those multiple sites because it can route to the most appropriate instance of an application. Today most appropriate is generally defined by geographically closest, but in some cases it can include things like “send our high-value customers to a different datacenter”. There are a ton of other issues with this type of distribution, not the least of which is database integrity and primary sourcing, but I’m going to focus on the DNS bit today, just remember that DNS is a tool to get users to your systems like a map is a tool to get customers to your business. In the end, you still have to build the destination out. DNS that supports IPv4 and IPv6 both will be mandatory for the foreseeable future, as new devices come online with IPv6 and old devices persist with IPv4. There are several ways to tackle this issue, from the obvious “leave IPv4 running and implement v6 DNS” to the less common “implement a solution that serves up both”. DNSSEC is another tough one. It adds complexity to what has always been a super-simplistic system. But it protects your corporate identity from those who would try to abuse it. That makes DNSSEC inevitable, IMO. Risk management wins over “it’s complex” almost every time. There are plenty of DNSSEC solutions out there, but at this time DNSSEC implementations do not run BIND. The update ISC is working on might change that, we’ll have to see. The ability to change what’s behind a DNS name dynamically is naturally greatly assisted by the aforementioned Wide IPs. By giving a constant IP that has multiple variable IPs behind it, adding or removing those behind the Wide IP does not suffer the latency that DNS propagation requires. Elasticity of servers servicing a given DNS name becomes real simply by the existence of Wide IPs. Keeping DNS servers synched can be painful in a dynamic environment. But if the dynamism is not in DNS address responses, but rather behind Wide IPs, this issue goes away also. The DNS servers will have the same set of Name/address pairs that require changes only when new applications are deployed (servers is the norm for local DNS, but for Wide-IP based DNS, servers can come and go behind the DNS service with only insertion into local DNS, while a new application might require a new Wide-IP and configuration behind it). Okay, this got long really quickly. I’m going to insert an image or two so that there’s a graphical depiction of what I’m talking about, then I’m going to cut it short. There’s a lot more to say, but don’t want to bore you by putting it all in a single blog. You’ll hear from me again on this topic though, guaranteed. Related Articles and Blogs F5 Friday: Infoblox and F5 Do DNS and Global Load Balancing Right. How to Have Your (VDI) Cake and Deliver it Too F5 BIG-IP Enhances VMware View 5.0 on FlexPod Let me tell you Where To Go. Carrier Grade DNS: Not your Parents DNS Audio White Paper - High-Performance DNS Services in BIG-IP ... Enhanced DNS Services: For Administrators, Managers and Marketers The End of DNS As We Know It DNS is Like Your Mom F5 Video: DNS Express—DNS Die Another Day
