On 14/05/2019 01:27, Wietse Venema wrote: > Wietse Venema: >> If you look at the non-VPN captures, then you will see the following: >> >> - In one trace, we see a client ACK 138, followed by a client packet >> with ".<CR><LF>" (data 443:446, ACK 138, and a timestamp field >> tht is unlike those of al other packets in the stream). >> >> - In the other trace, we see that the ACK and ".<CR><LF>" packets >> are sent as one packet, with a normal timestamp field. >> >> - After this, the TCP connection is messed up, the server keeps >> transmitting "Queued as xxx", and the client keeps transmitting >> QUIT. >> >> This looks like the VPN mucks with TCP and screws up the protocol. > I verified this another time. On the SMTP client side, there is one packet, > and on the SMTP server side there are two. > > Here is a diff -U output for client-side and server-side pcap files. > > -TIMESTAMP IP 10.110.2.9.33256 > 10.1.3.134.smtp: Flags [P.], seq 443:446, > ack 1 > 38, win 211, options [nop,nop,TS val 2968348176 ecr 687501956], length 3: > SMTP: > . > +TIMESTAMP IP 10.110.2.9.33256 > 10.1.3.134.smtp: Flags [.], ack 138, win > 211, o > ptions [nop,nop,TS val 2968348176 ecr 687501956], length 0 > +TIMESTAMP IP 10.110.2.9.33256 > 10.1.3.134.smtp: Flags [P.], seq 443:446, > ack 138, win 211, options [nop,nop,TS val 1 ecr 0], length 3: SMTP: . > > On the client side we see that the client sends one TCP packet with > three data bytes (offset 443:446, content ".<CR><LF>"), an ACK for > server offset 138, and Timestamp Value 2968348176 and Timestamp > Echo Reply 687501956. > > On the server side we see that the server receives two TCP packets. > > - One packet with the same ACK for server offset 138, and the same > Timestamp Value 2968348176 and Timestamp Echo Reply 687501956, as > the client sent, but no data bytes. > > - One packet with the same ACK for server offset 138, and the same > three data bytes as the client sent, but with a Timestamp Value of > 1 and a Timestamp Echo Reply of 0. > > And from here on TCP appears to be stuck. The server repeatedly > sends "Ok: queued as 58CE8C0058<CR><LF>" and the client repeatedly > sends "QUIT<CR><LF>". > > Anyway, something is breaking TCP and it isn't Postfix. Maybe the > VPN is trying to be too smart, maybe something in your TCP stack > is trying to shape traffic and messing up. > > Wietse
The packet sent by the client with the QUIT command never makes it to Postfix on the server, which therefore remains waiting for 300 seconds before sending the 421 response for timeout. Specifically, Postfix never sends a BYE since it doesn't see the QUIT. The TCP traffic after the QUIT is retransmissions that start on the server due the QUIT packet not being received. If the QUIT packet were being lost along the way over the VPN, what I would expect is for it to show up in the source pcap but not in the destination pcap, but it is in both and that seems to suggest it is being lost afterwards. fhare, can I ask if you took the destination trace on the server itself or on an intermediate node (for example on a vmware host)? John
