Hello, we're using an F5 BIG IP active/passive cluster to loadbalance Always On VPN connections. To avoid asymmetric routing we're using NAT, so the VPN gateway servers will always see the same IP address for the clients.We currently have src_addr persistence profile applied which results in the same VPN gateway server recieving all the connections - can anyone tell me what the best option would be for persistence so that the connections are balanced accross the VPN servers? We did try no persistence but this resulted in connection failures on the VPN clients.

Hi, Source address persistence should not result in one member receiving all traffic unless there is an upstream device that does source address translation and masks the actual client IP or -most likely- you are using a wide mask (0.0.0.0) in the source address persistence profile, which is the default if you choose none for the mask field. You may need to narrow this mask to something like 255.255.255.255 to have a unique persistence entry for each /32 address. Also check this: https://cdn.f5.com/product/bugtracker/ID752933.html

Hello Amine, yes we're doing source address translation so therefore the backend servers do not see the client IP address, they just see the address of the physical interface on the F5 - this means that due to the persistence profile, it keeps sending all clients to the same backend server - so I was wondering what my other persistence options are to avoid that and have proper loadbalancing accross all backend servers

SNAT is not the problem here IMHO, as it should not affect the load balancing between backend servers nor the persistence entry. Just check the persistence mask in the source address profile and make sure it is tight enough.You can also issue the following command to display the current content of the source address persistence table:tmsh show ltm persistence persist-records all-properties

Hello Amine, thanks once again for getting back to me - I've assumed that it is sending everyone to the same backend server but thats only based on 3 test connections which were all sent to the same server (we have 3 backend servers) - so do you think adding 255.255.255.255 to the mask will result in proper loadbalancing, even though all connections will come from the same IP address?

Yes yes, sure. Picking the pool member (either from a persistence entry or as a result of the LB algorithm) will occur before the SNAT, so F5 will base its traffic forwarding on the actual IP it sees in the ingress packet.And regarding the mask 255.255.255.255 this is just a mean to share persistence entries between multiple same subnet hosts, so by putting 255.255.255.255 you basically tell the F5 to create a persistence record for each unique host.(Note: as I mentioned in my 1st answer, this assumes you don't have an upstream device -before F5- that hides the actual user IP, which is a rare but possible scenario)

Persistence and NAT | DevCentral

11 Replies

Amine_Kadimi
MVP
Jan 02, 2021
Hi,

Source address persistence should not result in one member receiving all traffic unless there is an upstream device that does source address translation and masks the actual client IP or -most likely- you are using a wide mask (0.0.0.0) in the source address persistence profile, which is the default if you choose none for the mask field. You may need to narrow this mask to something like 255.255.255.255 to have a unique persistence entry for each /32 address.

Also check this: https://cdn.f5.com/product/bugtracker/ID752933.html
- Enfield303
  Nimbostratus
  Jan 07, 2021
  Hello Amine, yes we're doing source address translation so therefore the backend servers do not see the client IP address, they just see the address of the physical interface on the F5 - this means that due to the persistence profile, it keeps sending all clients to the same backend server - so I was wondering what my other persistence options are to avoid that and have proper loadbalancing accross all backend servers
Amine_Kadimi
MVP
Jan 07, 2021
SNAT is not the problem here IMHO, as it should not affect the load balancing between backend servers nor the persistence entry. Just check the persistence mask in the source address profile and make sure it is tight enough.
You can also issue the following command to display the current content of the source address persistence table:
tmsh show ltm persistence persist-records all-properties
- Enfield303
  Nimbostratus
  Jan 07, 2021
  Hello Amine, thanks once again for getting back to me - I've assumed that it is sending everyone to the same backend server but thats only based on 3 test connections which were all sent to the same server (we have 3 backend servers) - so do you think adding 255.255.255.255 to the mask will result in proper loadbalancing, even though all connections will come from the same IP address?
Amine_Kadimi
MVP
Jan 09, 2021
Yes yes, sure. Picking the pool member (either from a persistence entry or as a result of the LB algorithm) will occur before the SNAT, so F5 will base its traffic forwarding on the actual IP it sees in the ingress packet.
And regarding the mask 255.255.255.255 this is just a mean to share persistence entries between multiple same subnet hosts, so by putting 255.255.255.255 you basically tell the F5 to create a persistence record for each unique host.
(Note: as I mentioned in my 1st answer, this assumes you don't have an upstream device -before F5- that hides the actual user IP, which is a rare but possible scenario)
Enfield303
Nimbostratus
Jan 13, 2021
Thanks Amine - yes we do have upstream devices also doing SNAT:

client machine on internet
|
|
\|/
Azure cloud loadbalancer (required for cloud F5 loadbalancer failover)
I
|
\I/
Cloud F5 loadbalancer
|
|
\|/
Organisation firewall
I
|
\I/
Internal F5 loadbalancer
|
|
\|/
Backend VPN servers

I'm assuming that if I disable source address translation / SNAT on everything above the internal F5 loadbalancers then it should work as you've described?
Amine_Kadimi
MVP
Jan 13, 2021
In that case internal F5 will see all the traffic as coming from the same IP so you won't be able to persist based on source IP. One alternative is to inject X-Forwarded-For header from the upstream device and retrieve it in the LB and persist based on it using an irule. You can find an example here: https://devcentral.f5.com/s/question/0D51T00006i7grt/enable-source-ip-persistence-based-on-x-forwarded-ip-info
- Enfield303
  Nimbostratus
  Jan 18, 2021
  Thanks again Amine; does that work even when my traffic is not HTTP (its port 4500 & 500 UDP VPN traffic)
  - Amine_Kadimi
    MVP
    Jan 18, 2021
    Sorry, I didn't notice that this is for vpn traffic. In this case xff header is not applicable as it only works with http(s) traffic

Forum Discussion

Persistence and NAT

11 Replies

Recent Discussions

F5Access | MacOS Sonoma

Transaction looks successful but file not downloading

Overwriting or adding LTM SSL Traffic cert and key using iControlREST

F5 Access Guard Deprecated: ZTA APM

F5 loadbalancer not working

Related Content

BIG-IP AFM設定例-NAT

Decoding the IPv4 address from the persistence cookie

Remove subnet from NAT pools without any impact

Setting up persistence in F5 XC

NAT traffic initiated by F5