Forum Discussion
Enfield303
Nimbostratus
NimbostratusPersistence and NAT
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.
Amine_KadimiMVP
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
Enfield303Hello 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
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
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
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
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
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
Thanks again Amine; does that work even when my traffic is not HTTP (its port 4500 & 500 UDP VPN traffic)
- Amine_Kadimi
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