I have two domain controllers serving up a NLB VIP for ADFS authentication. The client is able to ping and RDP to both servers but it is unable to get an ack bit from either server. When I take a capture I see the SYN bit sent and re-transmitted,then crickets. I have confirmed that the firewall isn't dropping packets and tracetoutes and DNS resolution are successful. This one is a head scratcher so I was hoping for some insight. Thanks in advance!
asked 16 May '16, 07:32  it_ninja |
3 Answers:
If you don't see the SYN packets at the server, then it's likely your IPSEC tunnel is dropping them. You'll have to check the tunnel ingress and egress settings. Does the tunnel also NAT the client IP, so it's presented as something on the server's local network? answered 17 May '16, 03:00  grahamb ♦ Thank you. I was actually able to confirm that the issue was a limitation from the vendor’s equipment. I have submitted a ticket to their QA department and they are in the process of resolving the problem. This was my first post and I would like to thank everyone for their insight. I am learning that Wireshark is an INVALUABLE tool that I look forward to mastering (with the help of this forum) . (19 May '16, 07:49) it_ninja Your answer has been converted to a comment as that's how this site works. Please read the FAQ for more information. (19 May '16, 07:53) Jaap ♦ |
When you say you confirmed that the firewall isn't dropping packets, I assume you are talking about a different device. Have you checked that the Windows Firewall on the servers is allowing incoming traffic on those ports? answered 16 May '16, 11:29  ryber Thanks for your reply, Ryber. Yes, I confirmed that Windows Firewall is off and the servers are allowing incoming traffic on that port. This is only affecting users with an Ethernet connection on a SOHO router via an IPSEC tunnel and the logs don't indicate any traffic being dropped. (16 May '16, 11:43) it_ninja The statements
and
are not the same, are they? The only way to be sure that a box is not dropping packets is to capture at both its ends simultaneously and see the packets at the input of the box and not see them at its output. Plus it may not actually drop them, it may just misroute them somewhere else if it has several interfaces. (17 May '16, 05:17) sindy |
You mentioned that the client can ping and connect via RDP to either server. Can you see the TCP handshake completing for the RDP connections? If RDP works but HTTPS does not, then you may need to adjust the crypto map being used by your IPSEC tunnel (as grahamb suggested), or any other ACLs that might be along the way. answered 19 May '16, 07:43 ryber |
Presumably the client was taken at the client, what do you see if you capture at the server?
As ever, analysis by screenshot is hopeless, as a) we can't use the Wireshark tools for analysis and b) you may have cut out the frames in the capture that reveal the issue.
Correct, Gramb. The capture was taken from the client. When I do a capture from the server I don't see anything coming from the source IP. The client is connected to a remote SOHO router that provides access via an IP Sec tunnel. Please forgive me for the screen-shot, this is my first post on the wireshark forum. I didn't want to give out my private IPs to the world. Thanks again.