Forum Discussion

CraigMo's avatar
CraigMo
Icon for Nimbostratus rankNimbostratus
Aug 12, 2016

forward proxy irule for ssh

I am trying to configured a VS as a forward proxy VS for ssh. The traffic flow is:

internal server --> F5 VIP --> Internet server

I have tried the below irule but the connectivity just hangs and I do not see entries in the log file. Any help and suggestions would be appreciated. What I think this irule does is searches for a string in the payload and if it matches then use pool1 else use pool2. Instead of making a VS for each instance of ssh I want to use a single VS and use an irule to direct traffic to the appropriate pool (Internet server). We have some instances where it is the same app server initiating the request for multiple applications so not able to "key" off the server IP address.

when CLIENT_ACCEPTED { TCP::collect } when CLIENT_DATA {

switch -glob [string tolower [TCP::payload ]] {

   "*abc.de.efg*" { 
      log local0. "customer1 payload is [TCP::payload]"
      pool pool1
     }
  default { 
      log local0. "cust2 payload is [TCP::payload]"
      pool pool2 
      }

}

TCP::release }

application delivery
BIG-IP
devops
iRules

3 Replies

Sort By
  • Mohamed_Lrhazi's avatar
    Mohamed_Lrhazi
    Icon for Altocumulus rankAltocumulus
    Aug 12, 2016

    Not sure what you want to do can be done, or at least that easily done... but make sure SNAT is enabled on the VIP, or enable it in the irule, maybe.

     

  • boneyard's avatar
    boneyard
    Icon for MVP rankMVP
    Aug 13, 2016

    my experience with TCP::collect is limited but when i read the documentation it seems to indicate you have the have an idea about how much data you want to capture and that you have to release it

     

    https://devcentral.f5.com/wiki/iRules.TCP__collect.ashx

     

    beyond that you are you sure that TCP::payload will contain that plaintext data?

     

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Aug 13, 2016

    Hi Craig,

    the used syntax of 

    [TCP::collect]
    followed by 
    [TCP::payload]
    and 
    [TCP::release]
    looks fine for me. The iRule should successfully collect the first TCP packet send by your client, inspect the received payload and then select a 
    [pool]
    based on the result and then just relase the collected packet and send it to the selected pool.

    So far so good, but unfortunately you will not find the FQDN of the accessed erver within the payload. The problem is that SSH does not reveal the used FQDN like the TLS protocol would do using its SNI extension. The only information that is send in the initial TCP packet exchange is the SSH-Agent / Version string of your SSH client and server: 

    Client -> Server : SSH-2.0-PuTTY_Release_0.67
Server -> Client : SSH-2.0-OpenSSH_5.3

    So in the end your intended iRule logic may work for you, if you're going to use different SSH clients for the individual SSH servers, or if you find a SSH client which would allow to overwrite the initial SSH-Agent / Version strings using additional command line options... 😞

    Cheers, Kai