This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

url not working over site to site vpn

0

we have site to site VPN office located at remote site and users accessing particular url from the office is getting request timedout.please help.

asked 22 Jul '14, 12:16

kalyan's gravatar image

kalyan
11224
accept rate: 0%

i have added capture below

(22 Jul '14, 12:29) kalyan

please post the capture file on google drive, dropbox or cloudshark.org and post the link here.

(23 Jul '14, 00:23) Kurt Knochner ♦

source and destination ip address respectively 172.25.2.107 &10.128.121.23 and the url which get stuck at initial screen as below

http://ellipsis.i3global.net/timetracking/home.asp

Link to capture files

https://www.dropbox.com/s/rrt1n7ps3ffd2x9/capture.zip

(23 Jul '14, 04:37) kalyan

could you please add a description for the three files in the ZIP?

(23 Jul '14, 16:33) Kurt Knochner ♦

I could see that there is riverbed involved in this traffic flow and your netscreen device is stripping riverbed probes(Looking at NOP fields) which is essential for optimisation.I also see HTTP 404 unauthorised "access is denied to invalid credentials" error.

(24 Jul '14, 00:37) kishan pandey

could you please add a description for the three files in the ZIP?

Hi Kurt, all the files are captured from same user machine who cannot access the url but during different time stamps.

Thank You.

(24 Jul '14, 04:22) kalyan

Hi kishan ,

You are right there is a netscreen device and Riverbed device and the LAN is behind RB ,do you recommend any changes on netscreen device ?please suggest.

Thank You.

(24 Jul '14, 04:26) kalyan

Are you sure he is providing proper credentials/access rights because 404 error is suggesting that and to give detailed answer need capture from server end as well secondly can you provide capture from riverbed(both lan and wan interfaces).

(24 Jul '14, 05:27) kishan pandey
showing 5 of 8 show 3 more comments

One Answer:

0

The problem might be due to Windows client not offering a MSS option in the 3-way handshake. The largest segment sent and received by the client is 536 bytes. This might break the optimizaiton logic in RB. Here is one example from your traces at www.cloudshark.org

It looks like your large 'POST' requests never made it to the http server.

This problem was already discussed in thread tcp-mss-not-advertised-win2k8-r2-capture

answered 26 Jul '14, 22:52

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

edited 26 Jul '14, 23:41