Forum Discussion
MW1
Cirrus
CirrusFile 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:
4 Replies
MW1Thanks 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_53191Nimbostratus
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
hoolioCirrostratus
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- MW1Thanks 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
