TCP Retransmission (Port numbers reused) followed by Destination Unreachable

edit

Incidentally I was facing the port reuse issue with connection to ISP from enterprise users.

I am unable to comment on destination unreachable, but the port reuse is very interesting problem indeed, especially when it comes to firewalls and other such devices that are engineered to protect against DoS attacks such as SYN Floods.

I have taken the below snippet from doing a dig on the net:

"It means that within the capture file that you are viewing with wireshark, there is a SYN packet seen with the same ip-addresses and ports for which traffic has already been seen.

In itself, this is no problem, it is perfectly legal to have two TCP sessions after one another which have the same addresses and ports, as long as the first session is terminated before the second session begins.

what impact can it have for the clients on that net?

Well, the source and the destination system keep track of sessions so as long as they are OK with setting up sessions with the same ip addresses and ports, there is no porblem. But... firewalls, loadbalancers, ids systems and other systems that do something active with the traffic might keep state information. Even for a little while after the session has been terminated. It could be that one of those devices is sending out the RST packets because the new SYN's are matching older sessions.

Have a look at the TCP timers (especially TIME_WAIT) if you think this might be the source of the problem you are investigating.

Also, a typical client would run through a lot of sourceports before using the same source port again. So either these systems are opening a lot of tcp sessions, or in fact the src-ip's you see in your trace are actually from a natting device with many hosts behind it."

I can offer you something to try (at least). Contact your ISP as ask them to enable 'Dual-Stack' to your connection, in my case the port 'reuse' problem seems have been alleviated after ISP enabled Dual-Stack for the given subscriber and end-user.

"Communication administratively filtered" means that there is a kind of filter (router ACL or firewall). The system that sent the ICMP packet (62.73.73.128) is a good candidate for the ACL or firewall. So the SYN packets are blocked.

The ICMP packets also contain the TCP/IP headers of the original packet. I noticed a source address of 10.10.200.11. A 10.0.0.0/8 address is a private address and that is not allowed on the internet. So if Network Address Translation (NAT) is not applied by your SOHO router then that would explain the blockage.

Is this only the case of this destination (ctldl.windowsupdate.com) or does this also happen with other websites?

I'd also like to point out that my IP TV (from the same provider) has no issues at all during these periods.

So you have IPTV over Fiber (FtoH), like me. In my case IPTV and internet traffic is separated via 2 VLANs (at the WAN side). That would explain that IPTV has no issues, assuming you have the same setup (multicast traffic separated).

The issue appears periodically (not every day) and so far only in the evening at a random time.

Given that IPTVs VLAN typically uses a private IP-range, I suspect that in the error condition the traffic is routed via the IPTV VLAN. That could also explain the change in RTT reported by ping indicating the network path has changed.
Is DHCP (WAN side) set up correctly?