Forum Discussion
Using VIP IP as variable for SNAT
I've been working with F5s for about 10 months but I didn't have to play with iRules until a couple of days ago. I apologize if this is a newb question, but I've been looking through documentation online and I haven't been able to figure it out.
We are using 10.2.1 on some F5 LTMs, and there is a bug that is causing us to have to use an iRule to handle SNAT for some of our new VIPs (see http://support.f5.com/kb/en-us/solu...r=21731086).
The iRule itself is simple: when CLIENT_ACCEPTED {snat x.x.x.x} (the IP that we're giving it is the IP of the VIP).
That works well enough if I don't mind creating a new iRule for each VIP, but I'm wondering if there is a way to setup a variable for the VIP IP, and then use that for the SNAT. For example, something like this:
when RULE_INIT {
set VIP_IP IP::local_addr
}
when CLIENT_ACCEPTED {snat $VIP_IP}
I actually tried the above and the F5 accepted it without an error but it didn't work :)
Is it possible to do this? And, if so, could someone point me in the right direction?
Thanks!
- Richard__HarlanHistoric F5 Accountwhen the RULE_INIT there is no local addr for the connection.
- ascension2020_6NimbostratusRichard,
Thanks for the feedback. I had tried using IP::local_addr as the snat but the F5 doesn't like the syntax. That's when I got the idea to try setting IP::local_addr as a variable.
This is the error that I get when I tri "snat IP::local_addr":
"01070151:3: Rule [myrule] error: line 2: [Invalid IP address] [snat IP::local_addr]"
- hooleylistCirrostratusYou can enclose the IP::local_addr command in square braces to execute it and return the value:
when CLIENT_ACCEPTED { snat [IP::local_addr] }
- ascension2020_6Nimbostratus
Aaron,
Enclosing it in brackets did the trick! Thanks for your help!
To clarify, we normally use SNAT pools, but in this case we're having to NAT IPSEC, and there's a bug in 10.2.1 that is causing it to fail when configured to use a SNAT Pool or SNAT Automap:
This is the result of a known issue. Forwarding virtual servers configured to use a transport layer protocol other than TCP or UDP, such as Encapsulation Security Payload (ESP), discard return traffic when a SNAT pool or SNAT auto map is enabled. When this issue occurs, the BIG-IP system receives the return traffic but does not associate it with the virtual server. Configuring a global SNAT for the traffic does not resolve the issue.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com