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

NAT breaks relative sequence numbers

0

I have a capture situation where traffic from a particular host is seen with a translated IP in one direction and an untranslated IP in the reverse direction. Wireshark treats this as two separate connections, and sets relative sequence numbers independently. Is there a way to force Wireshark to use the translated IP and the untranslated IP as a single connection for relative sequence number purposes?

asked 16 Jan '16, 10:51

PaulS's gravatar image

PaulS
1222
accept rate: 0%

(I know that I can disable the relative sequence numbers, but I'm looking for a way to still be able to use them.)

(16 Jan '16, 11:05) PaulS

(I imagine if I could capture the three-way-handshake at the very start of the buffer that might get very close to what I want, but usually the three-way-handshake happened before I started the capture.)

(16 Jan '16, 11:11) PaulS

One Answer:

0

In your situation, I would use TraceWrangler and its IPv4 replacement capability to substitute the IP address in one of the directions before starting the TCP analysis.

As NAT often translates also ports (strictly speaking NAT does not but in common language no one distinguishes between NAT and NAPT), it may be necessary to use also client port substitution at TCP layer.

Beware: When the current version of TraceWrangler substitutes tcp ports selectively by the "original" socket, it actually does that after already changing the IP. So if you want to substitute original socket (IP:port) A:a with B:b, your "anonymization" task has to contain two rules:

  • at IPv4 layer "Replace IP addresses by list", the table must contain "original IP" A and "replacement" B

  • at TCP layer "Replace TCP ports by socket list", the row in the table must contain "original IP" B, "original port" a and "replacement port" b.

@Jasper, is this intentional or it just happened?

answered 16 Jan '16, 11:25

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 16 Jan '16, 12:48

@sindy no, that sounds like a typical bug of the category "Jasper hasn't thought this through well enough" ;-)

Funny enough the reason for this annoying behavior is calculating TCP checksums: sanitized packets are reassembled from top to bottom (= TCP before IP), and for the TCP sequence I need to look at the IPv4 PseudoHeader. Which means that IPv4 addresses need to be sanitized early (before actually sanitizing the IPv4 layer), and that happens before doing the socket replacement thing.

Thanks for the "bug report" :-)

(16 Jan '16, 17:32) Jasper ♦♦

Fixed in the current semi-auto build.

(16 Jan '16, 17:56) Jasper ♦♦