 | 1 | initial version |
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.
| | 2 | No.2 Revision |
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.
