Will F5 single arm setup work without SNAT?

Yes it will work if you ensure that the response traffic returns through the LTM. If your pool members (server) utilize the LTM as their gateway, then the traffic will return through the LTM and should be processed successfully. (One caveat: Any clients that reside on the same subnet as your pool members will not work, as the pool member will respond directly to the client.)

If this is an HTTP virtual (or HTTPS but you can process traffic on the LTM unencrypted), you also have the option to provide the original client IP address in an 'X-Forwarded-For' header. This would allow you to enable SNAT if requried, while also providing 'real' client IPs to the pool member, albeit in application-layer data. See SOL4816 for more info on X-Forwarded-For.

Thanks Ed. We received response from an F5 professional services tech who said that this was not possible and that's why I thought of posting the question here at devcentral to get a second opinion. I will take your response to our architect team because they had already started planning for a 2 arm setup and that will require changes both on F5 / switch / firewall side. If what you say is true we will be able to avoid a lot of hassle if just by disabling SNAT we are able to retain the functionality that we already had with CSS 11503 before we migrated out of it.

PS tech told our architect almost EOD today so we haven't had a chance to discuss this at length with him or within our team. That PS tech worked with us for few hours last month and after that we have had few other techs rotate on our deployment. We have a call scheduled tomorrow to discuss various options. In our case, LTM production interface and the 3 servers that are load balanced behind it are on the same VLAN. Default Gateway of the servers is LTM floating IP and the firewall sends the traffic back to LTM Floating IP (for the Virtual Servers setup on LTM) which then sends traffic further to those 3 servers. I understand your predicament regarding why PS tech might have suggested that it may not work. I also find it hard to believe that these boxes (which cost more then 100k) wouldn't have this basic functionality that CSS 11503's had. The whole idea behind choosing LTM's as replacement was that we will be able to replicate our current CSS environment "as-is" and this is only the first pair of CSS's that we are replacing. There are several more that need to be replaced in our environment and it all depends on this pilot install goes. Thanks for your inputs.

Hi Ed, I was reading through the email that PS tech sent to my architect and in that he made following statements why this will not work, maybe you can shed more light based on that -

In a one armed solution some type of SNATing is required for laod balancing to work - either explicit SNAT pools or through AutoMap. You are right that if we don't use any type of SNATing, then the source IP is going to be visible on the end server. But, again if we are using a one armed solution, SNATing is a pre-requisite.

If we are using load balancing even with no SNATing, the outside client will not see the IP address of the server, on the return path, the IP address is re-written to be that of the VIP.

If we don't SNAT, the IP address of the source is not lost to the server, however, the server address is re-written on the way back to the client.

Unless we have the networking architecture to support this scenario - 2 arm network with server's gateway address pointing to F5 floating address, this will not work and you will get TCP RSTs.

There could be some confusion at face-value when asking the question, "Will F5 single arm setup work without SNAT?"

The terms one-arm and single-arm are often synonymous with using SNAT since a one-armed design is the most-used architecture when addressing the desire to not change all server gateways to point to the F5, thus requiring SNAT. One-armed refers to a load-balancer hanging off one VLAN, which may or may not be the VLAN on which pool members reside. If pool members are not on that VLAN, then they cannot use the F5 as the default gateway (obviously) and require SNAT, but if pool members do reside on that VLAN they may be able to use the F5 as the default gateway.

When looking to implement a new architecture or change a current architecture, you should examine EVERY possible traffic flow that you can think of. Get a whiteboard, a network guy, an architect, and your PS consultant (or F5-specialist) and draw out the proposed architecture. As I don't know your environment, I'd suggest that you start by mapping out the following scenarios:

("F5's VLAN" simply refers to the "one" VLAN on which the F5, pool members, and other layer 3 device reside. "pool member" refers to a server using the F5 as its default gateway)

• Load balanced traffic from a client on a remote VLAN to a virtual server that then sends traffic un-SNATed to a pool member in the F5's VLAN and the return traffic
• Load balanced traffic from a client on the F5's VLAN to a virtual server that then sends traffic un-SNATed to a pool member in the F5's VLAN and the return traffic (this won't work without SNAT which @Ed Summers pointed out in a previous post)
• Traffic initiated by a pool member to an external VLAN, and the response to the pool member from the external device. this may not work depending on the layer 3 device at the edge of the local VLAN. Outbound traffic will traverse the F5 since it is the pool member's gateway, but response traffic will go directly from the layer 3 device to the pool member since the layer 3 device is on the F5's VLAN.
• Non-load-balanced traffic from a client on a remote VLAN that is destined for a pool member (for example, SNMP queries) and the response. This will not work since the F5 will RST the response traffic since it did not see the original inbound request and considers it an out-of-state flow, which is common behavior for secure devices. There are some ways around this if absolutely necessary.

Other traffic-flow considerations should include protocols, too (UDP, ICMP, ARP, DHCP, multicast, etc.)

There could be some confusion at face-value when asking the question, "Will F5 single arm setup work without SNAT?"

The terms one-arm and single-arm are often synonymous with using SNAT since a one-armed design is the most-used architecture when addressing the desire to not change all server gateways to point to the F5, thus requiring SNAT. One-armed refers to a load-balancer hanging off one VLAN, which may or may not be the VLAN on which pool members reside. If pool members are not on that VLAN, then they cannot use the F5 as the default gateway (obviously) and require SNAT, but if pool members do reside on that VLAN they may be able to use the F5 as the default gateway.

When looking to implement a new architecture or change a current architecture, you should examine EVERY possible traffic flow that you can think of. Get a whiteboard, a network guy, an architect, and your PS consultant (or F5-specialist) and draw out the proposed architecture. As I don't know your environment, I'd suggest that you start by mapping out the following scenarios:

("F5's VLAN" simply refers to the "one" VLAN on which the F5, pool members, and other layer 3 device reside. "pool member" refers to a server using the F5 as its default gateway)

• Load balanced traffic from a client on a remote VLAN to a virtual server that then sends traffic un-SNATed to a pool member in the F5's VLAN and the return traffic
• Load balanced traffic from a client on the F5's VLAN to a virtual server that then sends traffic un-SNATed to a pool member in the F5's VLAN and the return traffic (this won't work without SNAT which @Ed Summers pointed out in a previous post)
• Traffic initiated by a pool member to an external VLAN, and the response to the pool member from the external device. this may not work depending on the layer 3 device at the edge of the local VLAN. Outbound traffic will traverse the F5 since it is the pool member's gateway, but response traffic will go directly from the layer 3 device to the pool member since the layer 3 device is on the F5's VLAN.
• Non-load-balanced traffic from a client on a remote VLAN that is destined for a pool member (for example, SNMP queries) and the response. This will not work since the F5 will RST the response traffic since it did not see the original inbound request and considers it an out-of-state flow, which is common behavior for secure devices. There are some ways around this if absolutely necessary.

Other traffic-flow considerations should include protocols, too (UDP, ICMP, ARP, DHCP, multicast, etc.)

Thanks Shaggy. The whole idea behind paying top dollar and engaging F5 PS was to have an F5 expert work with us to understand our CSS based setup (using WebEx as they had to work remotely) and understand all the intricacies of our environment (working alongside our network & architect team). You will be surprised to know that till date we have had 4 WebEx sessions and every-time we got a new F5 engineer assigned to us. We were told by our initial F5 tech that ours was a pretty "cookie cutter" setup i.e. CSS in a single arm design receiving traffic from internet (behind a firewall) and load balancing among 3 servers (all of which are on same vlan). In any case we are going back to the drawing board and having our strategy meeting tomorrow, because if F5 can't allow our load balanced servers to see real source IP's and we have to change it to dual arm just for this functionality then we will seriously consider not buying anymore of these LTM's.

Maybe you need to deploy using VLAN-GROUP .

FYI

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-11-4-0/7.htmlconceptid

Heya mate,

when we installed our first BiG-IP's years ago we went the "one-arm" path (essentially using SNAT for everything). The majority of the services that live on our units are web services, which we use the X-FORWARDED-FOR header inserted via the http profile to present the client's real IP address.

A couple of services were however, not web services and had a requirement of having the client's IP visible to the servers. We spun up a new VLAN for the servers to live in defined it on our datacenter core switch (no SVI, just layer 2 VLAN), added it to the port-channel to the BiG-IP etc etc, defined the VLAN on the BiG-IP, nailed in a static route to the BiG-IP (we're cheap :p ), made a couple of forwarding virtual servers, made some self IP's etc, set the servers's default gateway to be the newly created floating IP, created a pool, monitors etc. and created the virtual server with SNAT disabled. And things work!

This is how we initially got things working. VLAN groups, as mentioned above have been introduced and should simplify part of this. I haven't tested them out yet.....

Hopefully, something i've rambled on about can help you.....it's clock off time for me now :)