This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Spurious retransmissions, caused by source or destination?

0

We've got an external appliation which connects to a virtual IP on our firewall (port 80). The virtual IP is relayed to one of our internal servers.

The external application was recently moved to new servers (production and test environment) so we had to make some adjustments in our firewall to accommodate the new source IP's. For the production environment, everything is working great but for the test environment it isn't. As far as I can tell, the firewall rules are correct and even if we connect the test environment of the external system to the virtual IP of our production server, it still doesn't work.

When we try to connect the test environment, the only thing I can see in Wireshark on our internal server is a TCP Spurious Retransmission comming in, followed by a TCP Previous Segment not captured going out and finally, TCP ACKed unseen segment comming in. I do know a little bit about networking trafic, but this goes beyond my knowledge.

I understand that it's impossible to pinpoint exactly what is going on by this post, but it would be great if someone could tell me which server is most likely causing this, the external server or our internal server? Any suggestions are more than welcome!

Thanks in advance, Arnold

asked 18 May '15, 02:47

Arnold71's gravatar image

Arnold71
6113
accept rate: 0%

edited 18 May '15, 04:51

Can you upload a capture file? It's much easier to see what is going on that way - if you need to, sanitize it with TraceWrangler first, then put it on Cloudshark and post the link.

(18 May '15, 02:53) Jasper ♦♦

Without a Trace I think it is not possible to tell you a lot.

But about the meanings of Spurious Retransmissions you can have a look here: https://blog.packet-foo.com/2013/06/spurious-retransmissions/

And out of your description, it sounds a little bit, that some packets go another way through the network!? But it is just a feeling. So again without a trace it is not possible to tell you some hard facts.

You coul upload a trace at dropbox, cloudshark or somerwhere else, so somebody can help you further?

(18 May '15, 02:56) Christian_R

Thanks for your fast responses! Ofcourse, you are both totally right about the capture file. I didn't have the file from our last test at hand, so I tried to post this anyway. ;)

I will organise a new test and post the result here. I read the blog post and it did clarify a lot for me! The only thing I couldn't figure out was if packets actually do get lost or not.

Anyway, I will get back to you with more information. Thanks again for responing!

(18 May '15, 03:09) Arnold71

One Answer:

0

Further testing revealed a configuration error, somewhere between the external and internal server. Not sure what it was, but the access provider resolved it so this question can be closed. Thank you very much for offering your help!

answered 20 May '15, 04:59

Arnold71's gravatar image

Arnold71
6113
accept rate: 0%