Forum Discussion
ascension2020_6
Nimbostratus
NimbostratusUsing VIP IP as variable for SNAT
Hi folks,
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!
- when the RULE_INIT there is no local addr for the connection.
The following iRUle should do what you want
when CLIENT_ACCEPTED {
snat IP::local_addr
} 
ascension2020_6Richard,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]"
hooleylistCirrostratus
You can enclose the IP::local_addr command in square braces to execute it and return the value:when CLIENT_ACCEPTED { snat [IP::local_addr] }
You could also create a SNAT pool containing the virtual server IP address and add that SNAT pool to the virtual server to avoid using an iRule for this. An iRule would be particularly useful if you need to do this SNATing on more than one virtual server.
Aaron- ascension2020_6
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.