[THIN] Re: ICA, SYN, No ACK, possible stupidity
- From: Henry Sieff <hsieff@xxxxxxxxxxxx>
- To: "'thin@xxxxxxxxxxxxx'" <thin@xxxxxxxxxxxxx>
- Date: Tue, 16 Nov 2004 14:01:06 -0600
Not sure - its possible that since the initial 3 way with the connection to
2598 fails, the issue wouldn't come up. It depends if the Session
Reliability service handles the failed handshake better then the ICA service
itself (it probably doesn't proxy off to ICA until the session is fully
established).
If it doesn't show up, that might justify the upgrade.
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]On
> Behalf Of Lilley, Brian
> Sent: Tuesday, November 16, 2004 11:06 AM
> To: 'thin@xxxxxxxxxxxxx'
> Subject: [THIN] Re: ICA, SYN, No ACK, possible stupidity
>
>
> And, would the same issue exist with connections to 2598
> which have a separate
> xte.exe for each inbound connection.
>
> I guess that it probably does?
>
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]On
> Behalf Of Henry Sieff
> Sent: 16 November 2004 16:25
> To: Thin List (E-mail)
> Subject: [THIN] ICA, SYN, No ACK, possible stupidity
>
>
> Ahh yes, serendipity.
>
> An issue was referred to me a few days ago - users were
> having difficulty
> connecting to a published application. It turns out that one
> of the servers
> serving this particular app was fine, but I couldn't initiate an ICA
> connection to the other.
>
> Telnetted to 1494, got the ICA ICA ICA.
>
> Fired up ethereal. Launced ICA session - 3wayHS successful,
> but bam! RST
> packet sent from the server to me immediately afterwards. ?!?!?!
>
> Rebooted the server, fine for a second, then almost
> immediately, couldn't
> get in again.
>
> Did a netstat -an - noticed that although there was no users
> logged in,
> there was a connection from an external IP to the server on
> 1494, stuck in
> SYN_SENT state. Rebooted again, and the connection again came in.
>
> Fired up ethereal again, this time sniffing that server's
> traffic. We were
> getting a SYN from the IP address, and sending out our
> SYN_ACK, but we were
> never getting the final ACK. The machine in question was constantly
> resending that initial SYN, over and over.
>
> The IP was one of ours - there was a bug in the remote site
> router firmware
> and the incoming ACL was not functioning properly, so they were never
> getting our SYN ACK. Once a blocked the remote site, the
> issue on our end
> went away, but here is my concern:
>
> From our perspective, all that happened was the ICA listener
> received a SYN
> and no final ACK. This is trivial to do intentionally, and
> yet constituted a
> very effective DoS which I have subsequently duplicated in lab.
>
> Has anyone else seen this, and is the only answer to start
> using something
> like CSG or use something which can detect and respond to this at the
> perimeter?
>
> Thanks,
>
> --
> Henry Sieff
> Network Engineer
> OCA
> Ph: (504) 620-3420
> Cell: (504) 931-4638
> ********************************************************
> This Weeks Sponsor Emergent Online ThinCity Conference
> Join us at ThinCity 2004: The 1st Annual Emergent OnLine
> Technology Conference
> http://www.ThinCity.com
> **********************************************************
> Useful Thin Client Computing Links are available at:
> http://thin.net/links.cfm
> ***********************************************************
> For Archives, to Unsubscribe, Subscribe or
> set Digest or Vacation mode use the below link:
> http://thin.net/citrixlist.cfm
>
> ==============================================================
> ================
> This message is for the sole use of the intended recipient.
> If you received
> this message in error please delete it and notify us. If this
> message was
> misdirected, CSFB does not waive any confidentiality or
> privilege. CSFB
> retains and monitors electronic communications sent through
> its network.
> Instructions transmitted over this system are not binding on
> CSFB until they
> are confirmed by us. Message transmission is not guaranteed
> to be secure.
> ==============================================================
> ================
>
> ********************************************************
> This Weeks Sponsor Emergent Online ThinCity Conference
> Join us at ThinCity 2004: The 1st Annual Emergent OnLine
> Technology Conference
> http://www.ThinCity.com
> **********************************************************
> Useful Thin Client Computing Links are available at:
> http://thin.net/links.cfm
> ***********************************************************
> For Archives, to Unsubscribe, Subscribe or
> set Digest or Vacation mode use the below link:
> http://thin.net/citrixlist.cfm
>
********************************************************
This Weeks Sponsor Emergent Online ThinCity Conference
Join us at ThinCity 2004: The 1st Annual Emergent OnLine Technology Conference
http://www.ThinCity.com
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
Other related posts:
