Forum Discussion

TNY_122436's avatar
TNY_122436
Icon for Nimbostratus rankNimbostratus
Sep 24, 2013

iRule to snat on certain subnet

Hi all, I'm trying to figure out how to write an irule that can do proper snatting. Here is the scenerio: There is a virtual server: 10.100.188.65 backend servers are: 10.100.181.72 & 10.100.181.71

 

Vlan 881 = 10.100.181.0/24 self IP's = 10.100.181.1 (floating IP) 10.100.181.3 (local traffic IP)

 

Vlan 888 = 10.100.188.0/24 self IP's = 10.100.188.4 (floating IP) 10.100.188.5 (local traffic IP)

 

We are trying to ssh into the VIP (10.100.188.65) from 10.100.181.72. Right now it is not able to. So I've configured an iRule that looks like this but ssh doesn't work. Am I configuring something wrong?

 

when CLIENT_ACCEPTED {

 

if {[IP::addr "[IP::client_addr]/24" equals "10.100.181.0/24"]} {

 

snat automap } else { snat none } }

 

4 Replies

  • You wouldn't want to use subnet notation on both sides of the evaluation. Try this:

    when CLIENT_ACCEPTED {
        if { [IP::addr [IP::client_addr] equals 10.100.181.0/24] } {
            snat automap 
        } else { 
            snat none 
        } 
    }
    
  • You can use a datagroup for mappings:

     tmsh list ltm data-group internal dg_source_snat
    ltm data-group internal dg_source_snat {
        records {
            10.131.131.0/24 {
                data 10.141.141.11
            }
            10.131.131.201/32 {
                data 10.141.141.10
            }
        }
        type ip
    }
    

    The iRule will try to match and select and apply the assigned SNAT:

    when CLIENT_ACCEPTED {
    
        snat [class match -value [IP::client_addr] equals dg_source_snat]
         log local0. "[class match -value [IP::client_addr] equals dg_source_snat]"
    }
    
  • According to your TCPDUMP you´re the connection is closed by the virtual server.

     

    A simultaneous TCPDUMP on serverside (use -i 0.0) would be helpful for further analysis.

     

    But I guess your poolmembers are not configured to port 22, right?

     

    The virtual server applies port translation on the destination port according to the poolmember settings. Perhaps they are configured to listen on port 80 and will reject the session setup.