Forum Discussion
how to deploy F5 BIG-IP 4200 V HA Pair for Web Application
Hi, We have recently purchased pair of BIG-IP 4200V (LTM & ASM) for our https based web servers load balancing. Web servers are located in DMZ of firewall. Web serves wants to see original source IP of the clients. We would like to know what is the best way to deploy BIG-IP whether Inline-Routed Mode or One-Arm. If we have to deploy it in Inline-Routed Mode. Do we have to use two different IP subnet or same? one for external & one for internal.
21 Replies
- Jason_40733
Cirrocumulus
We have deployed Virtuals with both the one-armed and the inline mode. How you do it is based off your specifics.
You need to retain the original IP address of the clients, if your web servers can examine the X-Forwarded-For or XFF identifier in the header, then doing an in-line will work well. You can offload the SSL to the F5 and still use all load balancing methods.
If you cannot look at the X-forwarded-for method, you can still use the in-line, but would need to have routes to the F5 for return public traffic. ( server default routes would point to the F5, any RFC-1918 routes would point to another gateway in our environment ).
The One Arm method works well for many things, but will remove your ability to offload the SSL and limit the load balancing choices ( no cookies.. someone correct me if I'm wrong here ). Typically each web server will need a loopback of the public IP to accept the One Armed traffic.
The Inline method does not require you to use different subnets. We do an inline method for many instances with all IPs in the same RFC-1918 subnet. We just have the firewall forward traffic for the public IP address of the load balanced web traffic to the failover RFC-1918 IP address of our LTM pair.
Hope this helps.
Jason
- Tabish_Mirza_12
Nimbostratus
As per my knowledge X-forwarded-for method only work for HTTP & SMTP traffic. It won't work for HTTPS traffic. As you said we can use same IP subnets on both interfaces (external & internal) of BIG-IP if we are deploying in Inline-Routed Mode. What is the pros & cons of using BIG-IP with same IP subnets or different ?
- Jason_40733
Cirrocumulus
You are correct if you're not terminating the SSL with the F5. However, If the F5 terminates the SSL connection from the client, it can insert the XFF header. This solution document gives some specifics. http://support.f5.com/kb/en-us/solutions/public/4000/800/sol4816.html There are no set pros or cons of keeping the F5 in the same subnet. It all depends on your specific environment. Since the web servers are already in the DMZ in this case, it saves IPs, subnets and VLANs to have it in the same subnet doing the inline. Simpler config, fewer problems is my standard goal. Other people may have more information, but this has worked well for us over many years. No problems thus far. Keep in mind, the F5 doesn't treat traffic any different when it sends it out on the wire. An IP is an IP and an interface is an interface to the F5.
- What_Lies_Bene1
Cirrostratus
Sorry but you are wrong Jason :) - most designs (exceptions are layer two only and nPath) do not limit your ability to offload SSL or the choice of load balancing or persistence methods available.
Loopbacks are not required for One Arm mode, only for nPath. A single device cannot have multiple interfaces in the same IP subnet (but a single interface can have multiple IPs in the same subnet).
There are quite a few variations where One Arm and Routed mode are concerned. Apologies Tabish but I don't have time to describe them here. I'd suggest you read the TMOS Implementations guide from support.f5.com for more detail.
- Tabish_Mirza_12
Nimbostratus
Now I am confused whether I can use same IP subnet on both interfaces (External & Internal) of single device or not. External interface pointing to client side & internal interface point to node (servers) side.
Pls help me.
- Jason_40733
Cirrocumulus
First let me clarify: One-armed: The F5 has one interface for load balancing. Two-armed: The F5 has an external and internal interface for load balancing. Npath: ( previously I errantly used "one armed" in place of this ) The Incoming traffic hits the F5, but the return path from the back end servers does not go through the F5. Here's an example: DMZ is the 10.10.10.0/24 subnet Public IP is 8.8.8.8 Web server A is 10.10.10.8 Web Server B is 10.10.10.9 F5 LB A is 10.10.10.5 for self IP F5 LB B is 10.10.10.6 for self IP F5 floating IP is 10.10.10.7. Back side of your firewall creating the DMZ is 10.10.10.1 Route the traffic for the 8.8.8.8 to the front side of your Firewall. Have the Firewall forward traffic for 8.8.8.8 to the 10.10.10.7 IP ( as the float it will follow the Active F5 in an Active/passive setup ). Your virtual would be set as 8.8.8.8 port 443. From there on, the config depends on your preference. Npath config: The VIP will NOT SNAT the traffic or terminate SSL. Your webservers would need a loopback of 8.8.8.8. The webservers would have 10.10.10.1 as their gateway. Not all load balancing options available. Non-NPATH: Virtual does a SNAT on the traffic, terminates SSL, and adds the X-forwarded-for to the clients. ( Use server side SSL if you like/need ). Other options are available. The F5 is very versatile. As far as one-armed vs two armed the big difference is the requirements of your environment. Npath vs the web server return traffic coming through the F5 ( we'll call that "inline" ) varies the different load balancing methods at your disposal.
- What_Lies_Bene1
Cirrostratus
You cannot have internal and external VLANs and associated IP addresses in the same IP subnet. In One Arm mode client and server side traffic would enter and leave using the same, single interface.
- Tabish_Mirza_12
Nimbostratus
Are you sure we can't have both (internal & external) interfaces of single unit in the same subnet ? Sorry the reason I am asking this because tomorrow I have to start implementation & Jason statement that (The Inline method does not require you to use different subnets. We do an inline method for many instances with all IPs in the same RFC-1918 subnet) made me confused.
- What_Lies_Bene1
Cirrostratus
I'm sure Jason will confirm or clarify that he was referring to a single VLAN implementation with a fixed IP on each of a HA pair and a floating IP for HA.
I'm just going to double-check on my VE that you can't assign IPs in the subnet to two different VLANs, just to be 100% sure but I'm 99% sure it'll throw an error. Standby...
- Tabish_Mirza_12
Nimbostratus
Customer wants to see the original source IP of the client on the Web Servers. Web servers are HTTPS based. As I know I can not go for One-Arm mode design because in One-Arm client source IP will change. In inline-routed mode (two arm) if we can not use same subnet on both interfaces then we have to change either web servers IP's or DMZ interface IP because currently server are using DMZ interface IP as a default gateway. Pls advise
- Jason_40733
Cirrocumulus
Quick clarification of terminology. One arm: F5 has a single interface for processing traffic. Two arm: F5 has an "external" and an "internal" interface for processing traffic. These are two different subnets on two different VLANS typically. Npath Routing: Incoming traffic comes into the F5 load balancer but does not return via the F5. This limits load balancing options. Note: You can do Npath routing in EITHER a one-arm or two-arm solution. Note: The differences between one-arm and two-arm solutions are only the subnets, IPs, VLANS, etc. There is no difference in how the F5 is able to manipulate or direct traffic. Even if the web servers are serving ONLY https... the same certificate can be loaded on the F5 and used to decrypt the data, then you add a server-side SSL and the connection to the Web servers will be re-encrypted. This is more load as you are decrypting and encrypting on the F5 on the way in and the way out. But is a functional way to move data that preserves all load balancing methods. One-Arm design does NOT have to change the source IP. Whether the source IP changes is determined by whether or not you have the Virtual server set to do SNAT. ( Source Network Address Translation ). - Tabish_Mirza_12
Nimbostratus
Jaison thanks for your clarification but I am not bother about SSL offload. I know I can do SSL offload on both design (Inline-routed mode or One-Arm mode). I am worried about original client source IP address as server teams wanna see original client source IP address on web servers. Server is HTTPS based. I can't go for X-forwarded-for method. Pls advise what is the best way to deploy BIG-IP in this situation.
- What_Lies_Bene1
Cirrostratus
OK, here's the error I got when trying;
01070354:3: Self IP 10.12.11.4 / 255.255.255.0: This network is defined on two vlans (/Common/internal and /Common/external) - What_Lies_Bene1
Cirrostratus
I think if you changed the default gateway for those specific web servers to be the F5 (and made the F5's gateway the fw) then it would work without the need for SNAT, using just a single VLAN on the F5.
Inbound: FW --> F5 VS --> Server Outbound: Server --> F5 --> FWIf you manage the servers through the same interface and don't want that to pass through the F5, just configure some static routes pointing directly to the f/w.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com