Forum Discussion
NimbostratusDifferent SNAT for each member in the pool
CumulonimbusYes, sounds like an iRule solution.
Try something like this:
when LB_SELECTED {
if { [IP::addr [LB::server addr] equals <IP-Poolmember1>] } {
snat <SNAT-IP-Poolmember1>
}
if { [IP::addr [LB::server addr] equals <IP-Poolmember2>] } {
snat <SNAT-IP-Poolmember2>
}
}
Regards Stefan :)
NimbostratusThank You so much Stefan,
The proposed iRule looks right and good but I cannot approve it as working solution,
I really sorry for that but in our case we use exactly similar iRule:
when LB_SELECTED {
if { [IP::addr [LB::server addr] equals 193.142.151.1] } {
snat 172.16.50.1
}
if { [IP::addr [LB::server addr] equals 193.142.151.2] } {
snat 172.16.50.5
}
if { [IP::addr [LB::server addr] equals 193.142.151.3] } {
snat 172.16.50.6
}
}(SNAT Pool includes these three Nodes: 172.16.50.1, 172.16.50.5, 172.16.50.6)
And in the FW LOG catched just after F5 we still see Requests from Src:172.16.50.5(6) to Dst:193.142.151.1 , and I can't understand this.
According the iRule such packets are impossible - When Dst:193.142.151.1 the only source IP must be 172.16.50.1
Respectfully,
Evgeni V.
- Paulius
MVP
What are the self-IPs and floating-IP of the interface on the F5 in that subnet? If you're still seeing requests from an IP that it shouldn't be coming from it is most likely the self-IP of the F5 doing it's health monitor queries. Without the information requested it's difficult to say why exactly this is happening.
- zamroni777
can you ensure those tcp sessions were created after the irules were applied?
if needed, you can delete existing tcp sessions to ensure
https://my.f5.com/manage/s/article/K53851362#Delete
