Forum Discussion

MW1's avatar
MW1
Icon for Cirrus rankCirrus
Feb 22, 2010

File transfers through F5 LTM failing

All,

 

I have to admit I was in two minds to post as I don't have much info but was hoping someone might either be familiar with the product or have some ideas to try. I'm trying to do routing to different IIS servers based on the URI with SSL offloading for a helpdesk ticketing system called ITSM by Frontrange. Behind the F5 I have two IIS webserver one hosting a site for the thick client version and another for the thin web browsers version. Both versions/sites work without issue bar being able to upload or download file attachements to the tickets. When attempting to do a transfer the user gets the error at the bottom of the post. I do have tried having SNAT both enabled & disabled with the same issue occuring. I'm presuming that a fresh conection is initiated which is failing to be passed by the F5, though I guess my next step will have to be to break out the packet sniffer (being a live situation it will take sometime to get permission to run this). If I do not terminate the SSL and jut set the F5 to route to one server/pool the transfers work without issue. I'm open to (and appreciate) any suggestions / ideas on to try on this one.

 

 

Apologies once again as a I know the info is limited

 

 

regards Matt

 

 

Heres the error:

 

 

Error List:

 

 

---------- EXCEPTION >>

 

FusionExceptionMessage: Error occured while downloading the file.

 

Source:

 

TargetSite:

 

StackTrace:

 

 

---------- EXCEPTION >>

 

ExceptionMessage: An unknown error occurred when communicating with the FrontRange Foundation server.

 

Source: mscorlib

 

TargetSite: Void HandleReturnMessage(System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Messaging.IMessage)

 

StackTrace:

 

 

Server stack trace:

 

at Fusion.Client.CompressionClientSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)

 

at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

 

 

Exception rethrown at [0]:

 

at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

 

at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

 

at Fusion.SoapTransferAgent.PrepForSending(String strRelativePathName)

 

at Fusion.RemotingStore.Load(String strRelativePathName, IProgressIndicator indicator)

 

at Fusion.Services.AttachmentWorker.Load()

 

---------- EXCEPTION >>

 

RemotingExceptionMessage: System.Runtime.Remoting.RemotingException: Requested Service not found

 

 

Source:

 

TargetSite:

 

StackTrace:
config
design

4 Replies

Sort By
  • MW1's avatar
    MW1
    Icon for Cirrus rankCirrus
    Feb 23, 2010
    Thanks for the response, the app admin has informed me that the web version works without issue. I orginally thought that the server needed to know it was HTTPS on the other end (ie client) so I had the F5 to do SSL to the backend server (have to terminate the SSL to route on the URI) . Since switching off SSL on the backend I know get:

     

     

    WebExceptionMessage: The underlying connection was closed: The connection was closed unexpectedly.

     

     

    Have to admit confused as it appears the client uses POST requests to download the file (per the bottom text)

     

     

    I've managed to do a packet capture on the server side (now its talking plain HTTP) ,however I'm a little stuck on the client side as its a thick client without trying to get a MITM proxy up and running (having a bit of prob turning the cert in to a jar keystore for some reason).

     

     

    Real long shot - is there anyway to perform a packet capture on the F5 of the packets its sending to the client prior to it being SSL wrapped?

     

     

     

     

    No. Time Source Destination Protocol Info

     

    737 12:49:34.774558000 192.168.56.132 192.168.56.214 HTTP POST /servicemanagement/AttachmentConnector.rem HTTP/1.1 (application/octet-stream)

     

     

    Frame 737 (272 bytes on wire, 272 bytes captured)

     

    Ethernet II, Src: F5Networ_67:63:1d (00:01:d7:67:63:1d), Dst: Vmware_95:06:28 (00:50:56:95:06:28)

     

    Internet Protocol, Src: 192.168.56.132 (192.168.56.132), Dst: 192.168.56.214 (192.168.56.214)

     

    Transmission Control Protocol, Src Port: 15615 (15615), Dst Port: http (80), Seq: 58576, Ack: 281657, Len: 218

     

    Source port: 15615 (15615)

     

    Destination port: http (80)

     

    Sequence number: 58576 (relative sequence number)

     

    [Next sequence number: 58794 (relative sequence number)]

     

    Acknowledgement number: 281657 (relative ack number)

     

    Header length: 20 bytes

     

    Flags: 0x18 (PSH, ACK)

     

    Window size: 32768

     

    Checksum: 0x72e9 [correct]

     

    [Good Checksum: True]

     

    [Bad Checksum: False]

     

    TCP segment data (218 bytes)

     

    [Reassembled TCP Segments (524 bytes): 730(306), 737(218)]

     

    Hypertext Transfer Protocol

     

    POST /servicemanagement/AttachmentConnector.rem HTTP/1.1\r\n

     

    Request Method: POST

     

    Request URI: /servicemanagement/AttachmentConnector.rem

     

    Request Version: HTTP/1.1

     

    User-Agent: Mozilla/4.0+(compatible; MSIE 6.0; Windows 5.1.2600.196608; MS .NET Remoting; MS .NET CLR 2.0.50727.3603 )\r\n

     

    Content-Type: application/octet-stream\r\n

     

    X-Compress: yes\r\n

     

    Host: qcare.medquist.com\r\n

     

    Content-Length: 218\r\n

     

    Expect: 100-continue\r\n

     

    \r\n

     

    Media Type

     

    Media Type: application/octet-stream (218 bytes)
  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    Feb 23, 2010
    There are two things that stand out as potential candidates here:

     

     

    1) I see that there's an X-Compress header being passed, as well as a reference to compression in the original stack trace. Are you using compression on this virtual server? If so, that could contribute.

     

    2) The 100 continue server response. I can't point directly to causality here, but this particular server response has proven tricky for me over the years...

     

     

    I know it's not much and this is very anecdotal, but hopefully it'll help the discovery effort...

     

     

    -Matt
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 23, 2010

    Real long shot - is there anyway to perform a packet capture on the F5 of the packets its sending to the client prior to it being SSL wrapped?

     

     

     

    Not exactly... but you could use an iRule to log the HTTP request headers that are sent to the server and any response headers that are received from the application. Or you could get a copy of the server's SSL key and use ssldump (either on LTM or another host) to decrypt the serverside portion of the tcpdump:

     

     

    SOL10209: Overview of packet tracing with the ssldump utility

     

    https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10209.html

     

     

    Aaron
  • MW1's avatar
    MW1
    Icon for Cirrus rankCirrus
    Feb 24, 2010
    Thanks all for the reply - I found out (rather embarassingly) that even when I hit the backend server on HTTP the file transfers seem to be forced over HTTPS, as I only packet captured on port 80 on the server I missed this totally. I'll use the private key and wireshark on a client which can do the same as ssldump to decrypt the packet capture (looks like I might need to downgrade the cipher used though), doing one direct to the server & another via the F5. I reckon my initial error was what the issue and the underlying connection clised must be a red herring.

     

     

    Matt