Ask Your Question
0

TCP Retransmission (Port numbers reused) followed by Destination Unreachable

asked 2022-08-04 17:17:11 +0000

Shadow_ gravatar image

Hello,

I am having issues with my internet for some time now (1-2 months) and unfortunately, my provider cannot find the cause for it. The issue appears periodically (not every day) and so far only in the evening at a random time. Both wired and wireless connections get affected and the connected devices show 'No internet' status for the network. I have tried ping with -n 200-500 and there are usually 3-15 packages lost. Ping is usually fine, although sometimes it gets up to 200-300 ms. According to my provider all is fine with their network. The connection is over optical wire. I'd also like to point out that my IP TV (from the same provider) has no issues at all during these periods.

I have recenlty found wireshark and made captures when the issue is present - both on wireless and ethernet. I do not understand the results though and would be grateful if someone can help with understanding them. What caught my attention are two record types that have not appeared while the connection is good:

23679 1198.088658 10.10.200.11 50.17.246.92 TCP 66 [TCP Retransmission] [TCP Port numbers reused] 2437 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1

23680 1198.090012 62.73.73.128 10.10.200.11 ICMP 70 Destination unreachable (Communication administratively filtered)

These always go one after the other. Here are links to the whole files: 1. Ethernet Capture 2. Wireless capture

I apologize if the information is not enough, this is the first time I am having such issue. I'd be happy to provide any additional information that might be useful.

edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted
0

answered 2022-08-11 17:46:13 +0000

ajaznawaz gravatar image

updated 2022-08-12 00:55:50 +0000

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.

edit flag offensive delete link more
0

answered 2022-08-04 20:17:34 +0000

André gravatar image

"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?

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2022-08-04 17:17:11 +0000

Seen: 268 times

Last updated: Aug 12