Revision history [back]

First. I have a capture file yet to-be wrangled and uploaded here.

Second. Remote user is attempting to RDP to AzureVM as follows:

User(Laptop) ------ Internet VPN --------AzureFW--------AzureLB-----------RDPgateway-----------AzureVM

On some occasions user is unable to RDP to AzureVM, simply fails to connection.

Upon observing captures taken from source host (i.e. user laptop), I have noticed an array of TCP streams as follows:

1. syn
2. syn-ack
3. ack
4. fin-ack
5. ack
6. fin-ack
7. ack

On each occasion the penultimate packet (fin-ack) is sent after 10-12sec from server side. The first fin-ack listed at point 4 above is client side, or client initiated.

I am struggling to understand why the first fin-ack followed by ack is not sufficient in terms of tearing down the connection and associated socket. The are some 19streams in the cap file all, and the conversation between this pair ending in the same way, a bit like a dead marriage with simply no future ..

I am also struggling to understand why there are so many short lived sessions here occurring between this particular client---server pair.

First. I have a capture file yet to-be wrangled and uploaded here.

Second. Remote user is attempting to RDP to AzureVM as follows:

User(Laptop) ------ Internet VPN --------AzureFW--------AzureLB-----------RDPgateway-----------AzureVM

On some occasions user is unable to RDP to AzureVM, simply fails to connection.connect.

Upon observing captures taken from source host (i.e. user laptop), I have noticed an array of TCP streams as follows:

1. syn
2. syn-ack
3. ack
4. fin-ack
5. ack
6. fin-ack
7. ack

On each occasion the penultimate packet (fin-ack) is sent after 10-12sec from server side. The first fin-ack listed at point 4 above is client side, or client initiated.

I am struggling to understand why the first fin-ack followed by ack is not sufficient in terms of tearing down the connection and associated socket. The are some 19streams in the cap file all, and the conversation between this pair ending in the same way, a bit like a dead marriage with simply no future ..

I am also struggling to understand why there are so many short lived sessions here occurring between this particular client---server pair.

First. I have a capture file yet to-be wrangled and uploaded here.

Second. Remote user is attempting to RDP to AzureVM as follows:

User(Laptop) ------ Internet VPN --------AzureFW--------AzureLB-----------RDPgateway-----------AzureVM

On some occasions user is unable to RDP to AzureVM, simply fails to connect.

Upon observing captures taken from source host (i.e. user laptop), I have noticed an array of TCP streams as follows:

1. syn
2. syn-ack
3. ack
4. fin-ack
5. ack
6. fin-ack
7. ack

On each occasion the penultimate packet (fin-ack) is sent after 10-12sec from server side. The first fin-ack listed at point 4 above is client side, or client initiated.initiated. No data is transferred by either side.

I am struggling to understand why the first fin-ack followed by ack is not sufficient in terms of tearing down the connection and associated socket. The are some 19streams in the cap file all, and the conversation between this pair ending in the same way, a bit like a dead marriage with simply no future ..

I am also struggling to understand why there are so many short lived sessions here occurring between this particular client---server pair.

First. I have a capture file yet to-be wrangled and uploaded here.

Second. Remote user is attempting to RDP to AzureVM as follows:

User(Laptop) ------ Internet VPN --------AzureFW--------AzureLB-----------RDPgateway-----------AzureVM

On some occasions user is unable to RDP to AzureVM, simply fails to connect.

Upon observing captures taken from source host (i.e. user laptop), I have noticed an array of TCP streams as follows:

1. syn
2. syn-ack
3. ack
4. fin-ack
5. ack
6. fin-ack
7. ack

On each occasion the penultimate packet (fin-ack) is sent after 10-12sec from server side. The first fin-ack listed at point 4 above is client side, or client initiated. No data is transferred by either side.

I am struggling to understand why the first fin-ack followed by ack is not sufficient in terms of tearing down the connection and associated socket. The are some 19streams in the cap file all, and where the conversation between this pair ending ends in the same way, a bit like a dead marriage with simply no future ..

I am also struggling to understand why there are so many short lived sessions here occurring between this particular client---server pair.

First. I have a capture file yet to-be wrangled and uploaded here.

Second. Remote user is attempting to RDP to AzureVM as follows:

User(Laptop) ------ Internet VPN --------AzureFW--------AzureLB-----------RDPgateway-----------AzureVM

On some occasions user is unable to RDP to AzureVM, simply fails to connect.

Upon observing captures taken from source host (i.e. user laptop), I have noticed an array of TCP streams as follows:

1. syn
2. syn-ack
3. ack
4. fin-ack
5. ack
6. fin-ack
7. ack

On each occasion the penultimate packet (fin-ack) is sent after 10-12sec from server VM side. The first fin-ack listed at point 4 above is client side, or client initiated. No data is transferred by either side.

I am struggling to understand why the first fin-ack followed by ack is not sufficient in terms of tearing down the connection and associated socket. The are some 19streams in the cap file where the conversation between this pair ends in the same way, a bit like a dead marriage with simply no future ..

I am also struggling to understand why there are so many short lived sessions here occurring between this particular client---server pair.pair with no exchange of data, seems rather inefficient user of resource !

First. I have a capture file yet to-be wrangled and uploaded here.

Second. Remote user is attempting to RDP to AzureVM as follows:

User(Laptop) ------ Internet VPN --------AzureFW--------AzureLB-----------RDPgateway-----------AzureVM

On some occasions user is unable to RDP to AzureVM, simply fails to connect.

Upon observing captures taken from source host (i.e. user laptop), I have noticed an array of TCP streams as follows:

1. syn
2. syn-ack
3. ack
4. fin-ack
5. ack
6. fin-ack
7. ack

On each occasion the penultimate packet (fin-ack) is sent after 10-12sec from VM side. The first fin-ack listed at point 4 above is client side, or client initiated. No data is transferred by either side.

I am struggling to understand why the first fin-ack followed by ack is not sufficient in terms of tearing down the connection and associated socket. The There are some 19streams in the cap file where the conversation between this pair ends in the same way, a bit like a dead marriage with simply no future ..

I am also struggling to understand why there are so many short lived sessions here occurring between this particular client---server pair with no exchange of data, seems rather inefficient user of resource !

First. I have a capture file yet to-be wrangled and uploaded here.

Second. Remote user is attempting to RDP to AzureVM as follows:

User(Laptop) ------ Internet VPN --------AzureFW--------AzureLB-----------RDPgateway-----------AzureVM

On some occasions user is unable to RDP to AzureVM, simply fails to connect.

Upon observing captures taken from source host (i.e. user laptop), I have noticed an array of TCP streams as follows:

1. syn
2. syn-ack
3. ack
4. fin-ack
5. ack
6. fin-ack
7. ack

On each occasion the penultimate packet (fin-ack) is sent after 10-12sec from VM side. The first fin-ack listed at point 4 above is client side, or client initiated. No data is transferred by either side.

I am struggling to understand why the first fin-ack followed by ack is not sufficient in terms of tearing down the connection and associated socket. There are some 19streams in the cap file where the conversation between this pair ends in the same way, a bit like a dead marriage with simply no future ..

I am also struggling to understand why there are so many short lived sessions here occurring between this particular client---server pair with no exchange of data, seems rather inefficient user use of resource !