Forum Discussion

walt_97468's avatar
walt_97468
Icon for Nimbostratus rankNimbostratus
Feb 09, 2010

inbound requests for FTP and sFTP

We have a need to send requests to different nodes within a pool, based on source IP address. For example if a request comes in from 172.16.95.5 send it to node 192.168.1.10, and if the request comes from 172.16.95.6, send it to 192.168.1.11. Here's what I have:

 

 

when CLIENT_ACCEPTED {

 

if { [IP::addr [IP::client_addr] equals 172.16.95.5] } {

 

use node 192.168.1.10

 

}

 

if { [IP::addr [IP::client_addr] equals 172.16.95.6] } {

 

use node 192.168.1.11

 

}

 

}

 

 

 

Will this work for inbound FTP request as well as sFTP (SSH)? How do I differentiate between these inbound protocols?

 

 

Any assistance is appreciated!

 

 

Walt

8 Replies

  • Hi Walt,

    Here is a slight adjustment

      
      when CLIENT_ACCEPTED {   
        if { [IP::addr [IP::client_addr] equals 172.16.95.5] } {   
           node 192.168.1.10 21  
        } else if { [IP::addr [IP::client_addr] equals 172.16.95.6] } {   
           node 192.168.1.11 21  
        }   
      }  
      

    You do not need to use "use", which is for BIGIP v4.x

    Can you explain a little more about what you mean in regards of differentiating inbound protocols. Are you looking to identify the protocols so you can send traffic over specific ports? An example would definitely help.

    I hope this helps,

    Bhattman

  • As SFTP and FTP run on separate ports, ideally, you'd configure a separate VIP for SFTP on port 22 and a VIP on 21 for FTP. For the FTP VIP you can add an FTP profile to allow LTM to handle the data channel natively.

     

     

    Aaron
  • Hoolio, Basically, we are migrating clients from an FTP/sFTP server to another box. As cleint's are migrated, we would send traffic based on that client's source address to either the existing FTP/sFTP node or the new FTP/sFTP node. So we would enable all ports on the Big IP VIP, and would only allow certain ports thru the firewall for this, as per the source IP address. We wouldn't do any port checking on the Big IP.

     

     

    For example, client A needs to send traffic via FTP. He's coming from IP 172.16.95.5. This request would get to the Big IP and based on the fact that it's coming from IP address 172.16.95.5 it would need to sent to node 192.168.1.10(let's say they haven't been migrated to the new node and would still need to get to the old) irregardless of if it's an FTP or sFTP session.

     

     

    Client B is coming from IP 192.168.1.11. They however have been migrated, so therefore their traffic would need to be sent to the new node, which would be 172.16.95.6.

     

     

    Does this make sense? I know it's a bit of a strange situation. Please advise and thanks!

     

  • If that's the case, I think you could use bhattman's iRule and remove the port on the node commands. If you don't specify a port on the node command, I believe LTM will not do destination port translation (and just use the same destination port the client used on the connection to the node address).

     

     

    If you have more than two client IP's to check for you could use a datagroup to store the client and destination IP addresses. If you do want to try this, can you confirm which version of LTM you're running? There are some changes to the datagroups in 10.1 that would make this simpler to do.

     

     

    Aaron
  • Aaron, I'd like to try the datagroups idea. We are still running version 9.2.3. Please advise and thanks!
  • Hi Walt,

    If you using datagroups

    You could define 2 datagroups

     
     class net1 { 
        172.16.95.5 255.255.255.255 
     } 
      
     class net2 { 
        172.16.95.6  255.255.255.255 
       } 
     

     
     when CLIENT_ACCEPTED {    
         if { [matchclass [IP::client_addr] equals $::net1] } {    
            node 192.168.1.10 
         } else if { [matchclass [IP::client_addr] equals $::net2] } {    
            node 192.168.1.11  
         }    
       }  
       

    Then you can define as many networks you want in these datagroups to correspond which node you would like them send the traffic to.

    I hope this helps

    Bhattman
  • Thanks Bhattman I will set this up in the lab to test. Appreciate the assistance!
  • If do have now or have had an active support contract while a more recent LTM version has been released, you could upgrade from 9.2.3 to a supported version. See SOL7727 for details (Click here). You can reactivate your license on license.f5.com to update the service activation date to the last time you had active support. 9.4.8 would be good from a stability perspective. 10.0.1 or 10.1.0 would be good from a feature perspective.

    For 9.2.x, you can use bhattman's example or you can create a single string datagroup containing the client destination IP and a corresponding server IP:

     
     class ip_mapping_class { 
        "1.1.1.1 2.2.2.2" 
        "1.1.1.2 2.3.4.5" 
     } 
     

    You could then use an iRule to check the client IP against the first field:

     
     when CLIENT_ACCEPTED { 
      
         Check if the destination IP is in the first field of the datagroup 
        set dest [findclass [IP::clientaddr] $::ip_mapping_class " "]  
      
         Check if there was a match 
        if { $dest ne "" } { 
      
            Use the match as the destination IP 
           node $dest 
        } 
     } 
     

    Aaron