For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

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

Show More
  • Eric_Van_Tol_10's avatar
    Eric_Van_Tol_10
    Icon for Nimbostratus rankNimbostratus
    Oct 13, 2005
    Okay, now I see it. I think the problem right now lies in the syntax of the rule itself. The 'remote_addr' is actually the remote address of the connection, not the remote address from the perspective of the snat process. So, if my rule is set up as such:

    
when LB_SELECTED {
   if { [IP::addr [IP::remote_addr] equals "172.19.10.0/24"]} {
       LB::reselect snat none
       log "In LB_SELECTED, using server:"
       log [IP::remote_addr]
   }
}

    and I attempt to telnet to my VIP on port 25 from 192.168.200.6, the remote_addr logged is 192.168.200.6, not 172.19.10.x. I tried local_addr, but that just shows 192.0.2.25 as the address (the address of the dummy VIP).
  • Eric_Van_Tol_10's avatar
    Eric_Van_Tol_10
    Icon for Nimbostratus rankNimbostratus
    Oct 13, 2005
    Posted By brandorr on 10/13/2005 10:34 AM

     

     

    Why don't you just set your two MX records that point to the two VIPs to equal weight?

     

     

    We thought of doing this, but the problem (from what I am told), with equal weight MX records, is that if one of the IPs is unavailable, the remote server will not attempt to make a connection to the second equally weighted MX IP. It would either bounce the message or queue it up.
  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Oct 13, 2005
    try:

     

     

    log "In LB_SELECTED, using server [LB::server addr]"
  • Brian_Gupta_115's avatar
    Brian_Gupta_115
    Icon for Nimbostratus rankNimbostratus
    Oct 13, 2005
    According to "DNS & BIND" 4th edition (O'Reilly) all equal weighted servers will be tried before going to a higher MX server.

     

     

    Why do they think that MX records work this way?

     

     

    Thanks,

     

    Brian