Forum Discussion
Eric_Van_Tol_10
Nimbostratus
Oct 10, 2005Selective SNAT rule
Hi all,
I am new to iRules and just implemented my first one today to resolve a problem we've been seeing with NAT. However, I need to create another one and I need to know the correct syntax to use. The setup is as such:
If I have a pool as such:
pool MB_pool {
lb method member ratio
snat disable
member 172.19.10.11:smtp monitor smtp_10.11
member 172.19.10.12:smtp monitor smtp_10.12
member 172.19.10.13:smtp monitor smtp_10.13
member 192.0.2.25:smtp session disable
}
How can I construct a rule that will prevent SNAT from occuring on the 172.19.x.x addresses, but will allow it on the 192.0.2.25 address? The 172.19.x.x addresses are physically located behind the BigIP, but the 192.0.2.25 address is on a remote network (a dummy VIP on a remote F5).
TIA,
eric
24 Replies
- JRahm
Admin
Try: (untested!)when LB_SELECTED { if {[IP::addr [IP::remote_addr] equals "172.19.10.0/24"]} { snat disable } }
You'll need to enable snat on the pool definition, though, to allow the snat to occur to 192.0.2.25, unless you want to add that into the rule as well - Eric_Van_Tol_10
Nimbostratus
I tried your suggestion, but that didn't work. I had to modify the 'snat disable' to be 'snat none', but that didn't work, either. Here is what I have now (using example IPs):
SiteA VIP: 192.0.2.10
SiteA Dummy VIP: 192.0.2.11
SiteB VIP: 192.0.2.24
SiteB Dummy VIP: 192.0.2.25
...pool MB_pool { lb method member ratio member 172.19.10.11:smtp monitor smtp_10.11 member 172.19.10.12:smtp monitor smtp_10.12 member 172.19.10.13:smtp monitor smtp_10.13 member 192.0.2.25:smtp monitor smtp_2.25 } snat MB { translation 192.0.2.10 origin 172.19.10.11 origin 172.19.10.12 origin 172.19.10.13 vlan internal enable } ... when LB_SELECTED { if { not [IP::addr [IP::remote_addr] equals "192.0.2.25/32"]} { snat none } else { use snat 192.0.2.10 } }
I could not get the 'snat none' to work until negating the 'if' statement and changing the remote_addr. The 'snat none' now properly disables SNAT for anything incoming, but does not use the 192.0.2.10 SNAT address for packets chosen to go to the remote dummy VIP. - unRuleY_95363Historic F5 AccountTry using this:
when LB_SELECTED { if {[IP::addr [IP::remote_addr] equals "172.19.10.0/24"]} { LB:reselect snat none } } - Eric_Van_Tol_10
Nimbostratus
Thanks for the suggestion, but that doesn't work, either. I get an "undefined procedure" error when I try to save the rule. I think it's getting hung up on the "LB:reselect". I tried putting a double-colon in there, but then I get a different error, "line 3: [command is not valid in current event context (LB_SELECTED)] [LB::reselect snat none". - Brian_Gupta_115
Nimbostratus
In this situation, because the LB_SELECTED event is in the server "context", and they want to check the client IP address, do they need to specify: clientside {IP::remote_addr}?
Thanks,
Brian - unRuleY_95363Historic F5 AccountEric: I apologize. This was only just changed in 9.2. You can work around it by disabling Rule validation with the following command:
You do need to use LB::reselect because when the LB_SELECTED event is triggered, both the server and snat have already been picked. Using just the snat command will not change the snat behavior at that point.[root@gumby:Active] config bigpipe db Rule.Validation none
Note: In 9.2, the LB_SELECTED event will be fired again after the LB::reselect (this is because a new LB decision is being made). You should add some logic to not reselect the snat if it has already happened once otherwise you'll create an indefinite loop (using a variable is usually easiest).
Brian: He actually wants to disable snat based on the server that was picked, not the clientside source address. - unRuleY_95363Historic F5 AccountYeah.
Just for clarification these are levels available:
strict - Check context, dependencies, syntax, etc. (the default).
check - Check the dependencies and syntax.
syntax - Tcl Syntax checking only.
none - No checking. - Eric_Van_Tol_10
Nimbostratus
Thanks, I disabled rule validation and it lets me save the rule now. However, the rule still doesn't work. I currently have SNAT enabled at the pool level and the rule is entered as:when LB_SELECTED { if {[IP::addr [IP::remote_addr] equals "172.19.10.0/24"]} { LB::reselect snat none } }
but this does not appear to disable SNAT for incoming connections for 172.19.10.0/24. tcpdump on a 172.19.10/24 server shows connections coming from the LB (172.19.10.1) as opposed to the original IP.You should add some logic to not reselect the snat if it has already happened once otherwise you'll create an indefinite loop (using a variable is usually easiest).
At the risk of sounding like a bonehead, how do I do this? Can you point me to some examples of this and maybe I can figure it out on my own? - unRuleY_95363Historic F5 AccountOk, you should try the negative logic (ie - don't select a snat until the LB_SELECTED event and then to a reselect). There could be a bug in the reselect logic for disabling the snat.
You don't need to worry about the loop until you move to 9.2. You would basically add something like this:when LB_SELECTED { if { not [info exists already_reselected] } { put the logic for the first time here. eg - code from above set already_reselected 1 } } - Eric_Van_Tol_10
Nimbostratus
Well, I tried many different permutations of the rule, using the negative logic and enabling/disabling SNAT and nothing works. I either A) can't get the snat to work to the remote dummy VIP, B) end up enabling snat for all nodes, or C) end up disabling snat for all nodes.
Looks like I have no choice but to go the more complicated route by using multiple pools with a combination of snat enabled/snat disabled.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
DevCentral Quicklinks
* 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
Discover DevCentral Connects
