Forum Discussion

jdscrymgeour_42's avatar
jdscrymgeour_42
Icon for Nimbostratus rankNimbostratus
Oct 27, 2011

TCP to UDP conversion / collection

Currently I have a setup that I receive a TCP message similar to a sending messages with netcat or telnet, that needs to be turned into UDP and sent across a network, I will then turn it back to TCP which is processed and then a reply is sent.

 

 

To make the TCP -> UDP conversion I use a sideband connection from the VS and send it to a UDP virtual server which happily receives the message, however when I then forward this message on and wait for a response I am losing messages because when a sideband connection is waiting for a response the collect does not continue.

 

 

I have been told that this could be possible using a SIP profile and using TMSH setting one profile as TCP and the other as UDP which would be nice and straight forward however I am currently struggling at trying to set this up and test it?

 

 

or is there a better way to deal with this using rules?

 

 

 

Thanks for your advise

 

James

 

6 Replies

  • Richard__Harlan's avatar
    Richard__Harlan
    Historic F5 Account
    Did this one a long time ago, note this was in version 9.4. But then you could go into the BigIP.conf file and make the client side profile TCP and the server side profile UDP. This forced the LTM to do a conversion for you.
  • Richard__Harlan's avatar
    Richard__Harlan
    Historic F5 Account
    this config in 9.4.4 would convert the packet from TCP to UDP

     

     

    virtual testsip3 {

     

    snat automap

     

    pool echopool

     

    destination 10.10.1.11:5007

     

    ip protocol udp

     

    sip

     

    tcp

     

    serverside

     

    udp

     

    clientside

     

    persist sip_info

     

    }

     

     

    Note if this is SIP you will still have to use a iRule to change the packet as a TCP SIP will say that it nned to be replied to in TCP. So you will need to flip UDP to TCP and TCP to UDP in the iRule but it should work.
  • Thank you for your comments Richard, the way that I managed to achieve this conversion was using the sideband connection feature introduced in version 11 to receive the TCP create a UDP sideband connection and then TCP respond any responses received back, which works fine for my application.

     

  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    Could you post a copy of your iRule for us to take a look at? We might be able to work around this, but I'm not quite sure until I see what it is you're trying to do.

     

     

    Thanks,

     

    Colin
  • The system I am using is very bespoke, the BIGIP receives a TCP packet and forwards the payload as UDP to a device and waits for a response to the request, the device then sends a UDP message back and I use the recv command for and then a TCP_respond with the data back to the client.

    I have removed some debug and additional checks I run on the message but below is my basic rule,

    sen
    
    when RULE_INIT {
    set ::DEBUG 0
    }
    
    when CLIENT_ACCEPTED {
    TCP::collect
    }
    when CLIENT_DATA {
    set DATA [ TCP::payload]
    TCP::payload replace 0 [TCP::payload length] " "
    if { $::DEBUG > 2 }{log local0. " HIGH OUT= :$DATA:"}
    regsub -all {[ ]+} $DATA "" DATA2
    
    set conn [connect -protocol UDP -status conn_status -idle 10000 -timeout 10000 172.31.2.2:49602]
    set send_info [send -status send_status $conn $DATA2]
     Setup RX connection, wait for response then reply to client
    }
    set recv_data [ recv -peek -eol -timeout 200 -status recv_status 18 $conn]
    }
    close $conn
    TCP::respond "$recv_data\r\n"
    unset recv_data
    }
    
    }
    }
     
  • I have a similar application need, thank you for this code snippet. Does the TCP server in your situation actually do anything? since you responding inside the F5 to the TCP client, i assume you just have a simple TCP listener? Does the TCP::respond command overwrite any response from the client? Do you need a physical TCP client with this setup at all? (other than keeping the pool member status happy?)

     

    Thank you, Damon