Can any one help me the below issue ?
Our uses have issue when accessing the website I suspect it’s related to our Bluecoat proxy. Could you help look into this issue?
Missing search bar on the frontpage:
This is the policy trace output
connection: service.name=weixin and whatsapp client.address=X.X.X.X proxy.port=80 client.interface=1:0.1 routing-domain=default
time: 2018-07-26 02:44:52 UTC
DNS lookup was unrestricted
authentication status='not_attempted' authorization status='not_attempted'
EXCEPTION(tcp_error): Request could not be handled
Not easy to say by looking the section of policy trace. Anyway the exception of TCP_Error is related to proxy not getting response for the SYN sent. Do check via a packet capture.
only issue is missing search bar on the frontpage:
If you could share the policy trace and pcap, I will check for you. If client want to fix this immediately, I would recommend a TAC case though.
Please find the policy trace and packet capture .
Our uses have issue when accessing the website http://wenshu.court.gov.cn/, We suspect it’s related to our Bluecoat proxy.
This is the full url
Only this url for now issue . I’ve tried to bypass the proxy to access this url which turned out OK though…
we deployed this proxy in transparent mode. We PBR all Internet traffic to the Proxy on our Proxy Switch.
Share new policy trace and screenshot. We need to check is there anything block on proxy.
If it TCP Error then share PCAP by filter host abc.com
The requests from proxy is getting a RST in return. This is what is causing the "Exception (TCP_Error)". Screenshot below
Even the landing page code is getting RST. The content user browser is getting could be from cache. It is not clear from this on why the RST. You may want to first confirm whether the RST is done by any device within your network or not. If it is beyond, it will be difficult to find root cause.
@Aravind: You can check the TTL of the RST packet to see whether it is coming from the OCS or from another device in between. Usually systems are using a TTL value of 64, 128 or 256. So if the RST packet has a TTL value of 126, whereas the other packets from the OCS arrive with a TTL of 58, the RST packet was probably not sent by the OCS but by an intermediate device 2 hops away.
Of course the TTL can be set to any value, so this is not a real proof, but the observations usually point in the right direction.
I have already checked this and the TTL for the SYN-ACK is havig 51 while the RST is 52. If we found the same RST on the customer's perimeter device, then we can put the blame on the OCS side (i.e. 1 hop before the actual server or load balancer).