Forum Discussion
J_Peterman_4266
Nimbostratus
NimbostratusHaving trouble with destination based SNAT irule
We are looking to implement destination based SNAT via iRule where all traffic destined to RFC 1918 space does not get SNAT outbound and it retains its private addressing, all other traffic destined to public addressing gets SNAT outbound for internet specific connectivity. The problem is that the iRule that I have created and applied to a basic IP forwarding Virtual Server is not matching and performing "snat none" or simply "forward" and instead all traffic outbound is getting SNAT. Can anyone point out what might be going on?
[IP addressing has been changed to protect the innocent]
Here is my iRule:
when CLIENT_ACCEPTED {
Check if the remote address is part of the private_nosnat data group
if { [class match [IP::remote_addr] equals private_nosnat]} {
don't do anything
log local0. "MATCH NO SNAT CLASS"
snat none
} else {
snat behind this address
snat 1.1.1.1
}
}
the datagroup private_nosnat includes three networks defined:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Again, this is applied to a virtual server that just matches all destinations and forwards on. The problem is that the first if statement isn't working and all traffic is getting SNAT on the final else statement.
Any insight is greatly appreciated.
Brian_Van_StoneAre you on v11?
Note that starting in v11, any data-groups that are configured in a partition other than Common must be referenced by /Partition_Name/Data-Group_Name, even by iRules configured in that partition. Data-groups referenced only by name are implicitly presumed to be /Common/Data-Group_Name.
https://devcentral.f5.com/wiki/iRules.class.ashx
J_Peterman_4266We were supposed to be on v11 shipped to us, but they arrived v10 and we've just been setting them up on v10 prior to upgrading. So I see that this is noted as a bug in v10, was this fixed in v11 so that we can use route domains in the group? Seems like a pretty big issue when you can't define route domains in a group, and a vast limitation.
If v11 fixes this bug, then I'll prioritize upgrading rather than getting these propped up and running first.- Brian_Van_StoneStill listed as a known issue in 11.2.0
ID 337222When creating an IP-based datagroup/class, any route domain information that is specified as part of the datagroup entries will be ignored by the iRule class, matchclass and findclass commands.
http://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-ltm-11-2-0.html
Looks like they just haven't updated the affected versions on the page about the issue.
http://support.f5.com/kb/en-us/solutions/public/12000/300/sol12301.html?sr=22838986 - J_Peterman_4266So, uhm...
With this limitation, how do they expect people to create complex irules to action based upon source or destination network ranges. I looked through the thread posted earlier but don't see a clear solution on how to make this work.
Full disclosure, iRules are still a learning curve since we've moved to the F5 platform from other load balancing platforms used prior. - J_Peterman_4266Working with our reps and support teams at F5 to get the latest info on being able to use these features within route domains.
- Brian_Van_StoneDoesn't help with the general case that much but I think this can solve this specific problem.
when CLIENT_ACCEPTED {
set local [IP::local_addr]
switch -glob $local {
10.* {
log local0. "MATCH NO SNAT CLASS"
snat none
}
172.1[6-9].* -
172.2[0-9].* -
172.3[0-1].* {
log local0. "MATCH NO SNAT CLASS"
snat none
}
192.168.* {
log local0. "MATCH NO SNAT CLASS"
snat none
}
default {
log local0. "MATCH AND SNAT"
snat 1.1.1.1
}
}
}
Not ideal, I agree, but hopefully the route domain handling with classes will get fixed soon. - Brian_Van_StoneIt won't let me edit my post and that's quit unreadable. Sorry...take two...
when CLIENT_ACCEPTED { set local [IP::local_addr] switch -glob $local { 10.* { log local0. "MATCH NO SNAT CLASS" snat none } 172.1[6-9].* - 172.2[0-9].* - 172.3[0-1].* { log local0. "MATCH NO SNAT CLASS" snat none } 192.168.* { log local0. "MATCH NO SNAT CLASS" snat none } default { log local0. "MATCH AND SNAT" snat 1.1.1.1 } } } 
hooleylistCirrostratus
Thanks for the example Brian. But I think it would be more efficient to strip the route domain off of the client IP and have a route domain-specific data group like in this example versus using string comparisons with switch.
https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/1172490/showtab/groupforums/Default.aspx1173766
J, please do open a case and escalate the request for a fix. I've also spoken with development and asked them to increase the priority on supporting route domains in data groups.
Thanks, Aaron- J_Peterman_4266The recommendation from F5 is to do the very same thing, to create an irule that strips the route-domain off the destination address (remote_addr) before making a comparison against the strings in the data group.
To be completely honest, I'm very disappointed that a feature that should be a no brainer in usage and application has been broken since the introduction of 10.x and route domains for nearly 2 years into the current release of 11.x.
We have a ticket open for an enhancement request via our account teams and have this escalated (most likely put with what I imagine is a pile of other similar requests from other companies).
Performing semi-complex string manipulation via TCL for in depth iRules (this is a simple example compared to most of our real world applications that would exist within route domains) is not something that I would consider user-friendly. This basically limits the daily usage and development of iRules to a handful of staff that are skilled in TCL scripting. Not exactly what I'd expect when paying a premium for a product against competitive offerings, so I hope that F5 understands the significance of this limitation and the burden of the work around and addresses it sooner rather than later. - hooleylistI agree that this should be fixed. It looks like the escalation requesting a fix is progressing.
Aaron