iRule for SNAT using subnet range rather than host base

Well I started this as an answer to the real use of SNAT, but after rereading your question, I am not sure why you would use a SNAT in this case. You want to allow different subnets to come into your site? If so, that seems to be a function for a firewall--which the BIG-IP is not. What I wrote below could still apply but for selecting a different pool or node rather than a SNAT. I left what I wrote in case it is of some use to someone.

Since you are snatting the same IP address, you could use an address class. You just put the subnets into the class and then use a class match statement to see if the [IP::client_addr] is in the class and if so, snat 10.1.147.13

Something like

if {[class match [IP::client_addr] equals "mySNATClass"]} {
   snat 10.1.147.13
}

Load up an address class named mySNATClass with the following and you are good to go:

• 170.42.6.0/24
• 70.40.6.0/24
• 16.52.171.0/24
• 200.52.171.0/22

If you want to vary the address you SNAT (something I believe a future post suggested), you could use a value in the address class and set the address to the subnet, then the value to the IP you want to SNAT. 

Something like this would work:

set snatAddr [class match -value [IP::client_addr] equals "mySNATClass"]
if {$snatAddr ne ""} {
   snat $snatAddr
}

For the above, load up the address class the same way, but add a value of the address you want to SNAT.

• 170.42.6.0/24 - 10.1.147.13
• 70.40.6.0/24 - 10.1.147.14
• 16.52.171.0/24 - 10.1.147.15
• 200.52.171.0/22 - 10.1.147.16

Error handling of ensuring the value in the class is an exercise left to the reader.

If you are new to classes, definetly read all the great material on them here on DevCentral.

Using the class approach makes the process more data-driven planning ahead for the inevitable additions to your If statements.

Good luck.