F5 Client IP Address

Question

DearsI m setting up f5 LTM and AWAF and they are two separate boxes, i would like to know the belowThe traffic should be received by LTM first or AWAF ?, if AWAF ?&nbsp; then how AWAF will inspects the https traffic becz it is encrypted.I don't want to buy SSL orchestrator becz i dont have seperate IPS, i would like to do inspection of the traffic by the AWAF itself is that a correct&nbsp;In my opinion the traffic should hit to LTM first it should be ssl off loaded and the clear text traffic should be send it to the AWAF, please correct me ? if this is the case then AWAF has to be positioned in layer 2 mode ( bump in the wire ) is this mode available in f5 ? and please suggest if this design approach is correct ?I would like to preserve client IP Address and i dont want a perform source NAT neither i want to change the default gateway of the servers from firewall to f5, is there any way to preserve the client Public ip address? by any of the design.Please do not suggest me to involve local country f5 system engineer to help me.&nbsp;Thanks

mohamed_ahmed_kansoh · Answer

Hi ,&nbsp;I will reply to your points according to each point in the query:&nbsp;

you should put AWAF first not the LTM.&nbsp;
you don't need SSLO you can use same Certificate which you will use in the LTM in the Client side , you can do the ssl offloading by AWAF same as LTM exactly.
No for the optimal use , you should use AWAF then LTM behind it.&nbsp;

the traffic flow should be :

you will create a Virtual server for each application on AWAF , then use the Client ssl profile&nbsp; and http profile and AWAF policy.
you should go to the LTM device , the create another Virtual server for the same application and behind it the Pool of servers.
the last step you will create the LTM Virtual server in (step 2) as a pool member in a pool, this all be done in AWAF.

the last point of preserving the Client Public IP:&nbsp;

you can do that by disabling SNAT options ( Auto map or SANT pool ) , but in this case you will create only one route as a default route to send any traffic to the LTM ( as a Next hop I mean the self IP of the LTM [ Floating self if HA or non-floating self if Standalone] ).
Do you have a Firewall between AWAF and LTM or not , because this will be the main issue as in this case I don't see it has a benefit in this design.
it's Okay to place it before servers ( between LTM and Servers ) but you will need to use Auto-map option or SNAT pool.&nbsp;
you can depend on XFF header to preserve the public IP.

&nbsp;
Let me know if you have further concerns :)&nbsp;

ragunath154 · Answer

You can use AWAF only with SSL offloaded as the F5 AWAF inbuilt with LTM functionality which is necessary for HTTP applications.check the below link for LTM features available within AWAF license&nbsp;https://my.f5.com/manage/s/article/K14231234If you have any policy to use LTM at edge&nbsp; with ssl offload and AWAF with Plain HTTP traffic and keep the Public IP visibility in WAF and server then you have to rely on the XFF (X-Forwarded-For) header value.[LTM inserts the Client IP in X-Forwarded-For header&nbsp; and in AWAF http profile with&nbsp; accept XFF, and waf policy with Trust XFF should be enabled)But XFF value can be Spoofed and AWAF will not be much effective to block if multiple ip address are present in XFF header and also L7 DOS will not be effective.as suggested by Mohamed_Ahmed_Kansoh's better use AWAF at edge(so AWAF take action on L3 IPaddress value)&nbsp; and LTM to load balance your servers. Either you can use&nbsp; Full SSL&nbsp; ie SSL in AWAF and SSL offload in LTM. or SSL only in AWAF and plain HTTP in LTM and backend servers**one more advantage of using AWAF at edge , as you can use the Priority Group option to failover, to direct servers in case LTM fails or down.&nbsp; A pool With both&nbsp; LTM VIP and Backend server IPs a members,&nbsp;&nbsp; LTM VIP member with higher priority and priority group value less than 1. If LTM VIP /device is down the traffic will be load balanced to backend servers along with waf capability.&nbsp;&nbsp;

adam_gibs · Answer

DearsThanks for the replies, please confirm the below thoughts will work in my designPlease find the attached diagramWAF DG is firewallNexus DG is firewallNexus has routes to reach internal networksLoad Balancer DG is Nexus&nbsp;Here is the traffic flow: Incoming traffic to serverInternet client is trying to access the web servertraffic reaches on FW,&nbsp;FW NAT's to private address VIP towards WAFWAF' destination is Load balancer VIP so it forwards the traffic to nexus switch (1/6) by its internal interface ( keeping source IP as it is received from internet i.e PUBLIC IP)Nexus switch sends to Load balancerLoad balancer looks for the server IP and forwards by source NAT and sends it to the nexus switchNexus switch send the traffic downwards to DC FW and then to the servers&nbsp;Return Traffic from serverserver's send the packet to DCFW and then to nexus switchnexus switch looks the destination is load balancer IP so it forwards to Load balancerFor Load Balancer the destination is PUBLIC IP and it sends to the default route to nexus switchAnd nexus switch according to his default route it send traffic to perimeter firewall and not to AWAF this becomes a problem and asymmetric routing occurs&nbsp;Solution:I will keep f5 in one arm mode and the DG will be nexus switchI will configure interface vlan 10 on switch with ip add 10.1.1.1 and assign 2 ports on switch ( 1/7, 1/6) in vlan 10AWAF to reach LTM VIP , AWAF will do arp request on LTM VIP and to reach to direct servers it will have a route pointing to vlan 10 interface ip ( 10.1.1.1) on switch.For the return traffic I will enable&nbsp;auto last hop on the virtual server or vlan , that will help for bypassing the local routing table of LTM sending packets towards switch interface vlan 10 IP address becz LTM default gateway is interface vlan 10 on switch and by enabling auto last hop on the virtual server or vlan it will send it to AWAF MAC Address from where it received the connection. https://my.f5.com/manage/s/article/K13876&nbsp;Please confirm whether this traffic flow will work.&nbsp;

Forum Discussion

SSO Login Update Coming to DevCentral

Kevin - June 2026 Featured F5er

Tyler - May 2026 Featured Member

Recent Discussions

Related Content

F5 Distributed Cloud - Traffic Steering based on Client IP Address

Addressing Shadow AI with F5 BIG-IP SSL Orchestrator

F5 BIG-IP deployment with Red Hat OpenShift - keeping client IP addresses and egress flows

Fingerprinting TLS Clients with JA4 on F5 BIG-IP

Destination address at F5

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS