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.
