Forum Discussion

Eric_Van_Tol_10's avatar
Eric_Van_Tol_10
Icon for Nimbostratus rankNimbostratus
Oct 10, 2005

Selective 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
application delivery
dev
devops
iRules

24 Replies

Sort By
  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Oct 10, 2005
    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's avatar
    Eric_Van_Tol_10
    Icon for Nimbostratus rankNimbostratus
    Oct 10, 2005
    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_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Oct 11, 2005
    Try 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's avatar
    Eric_Van_Tol_10
    Icon for Nimbostratus rankNimbostratus
    Oct 11, 2005
    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's avatar
    Brian_Gupta_115
    Icon for Nimbostratus rankNimbostratus
    Oct 11, 2005
    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_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Oct 11, 2005
    Eric: I apologize. This was only just changed in 9.2. You can work around it by disabling Rule validation with the following command: 
    [root@gumby:Active] config  bigpipe db Rule.Validation none
    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.

    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_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Oct 11, 2005
    Yeah.

     

     

    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's avatar
    Eric_Van_Tol_10
    Icon for Nimbostratus rankNimbostratus
    Oct 11, 2005
    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_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Oct 11, 2005
    Ok, 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's avatar
    Eric_Van_Tol_10
    Icon for Nimbostratus rankNimbostratus
    Oct 13, 2005
    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.