Subject: kern/17656: After other-host reboot, TCP ACKs being sent w/o ESP
To: None <gnats-bugs@gnats.netbsd.org>
From: None <wrstuden@netbsd.org>
List: netbsd-bugs
Date: 07/20/2002 00:20:27
>Number:         17656
>Category:       kern
>Synopsis:       After other-host reboot, TCP ACKs being sent w/o ESP
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 19 17:21:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Bill Studenmund
>Release:        Mid-June 2002 macppc -current kernel
>Organization:
NetBSD
	
>Environment:
	
System: NetBSD tanis 1.6B NetBSD 1.6B (TANIS) #39: Thu Jun 20 19:16:56 PDT 2002     wrstuden@tanis:/y/src/sys/arch/macppc/compile/TANIS macppc


>Description:
	I have a desktop macppc (with monitor) and a laptop i386.
Typically I work at the macppc and ssh to the laptop. I also direct
X back to the desktop. As I have IPsec/ESP set up between them,
xhost <laptop> suffices.
	I rebooted the laptop, and I was then able to have X
programs connect to the desktop. I had ssh'd in and set
DISPLAY=<desktop>:0 . X programs would just time out trying to connect
to the display.
	tcpdump shed some information:
# tcpdump -i wi0 -pn port 6000
tcpdump: listening on wi0
17:00:05.227262 10.0.0.2.6000 > 10.0.0.7.65508: S 6581671:6581671(0) ack 2255666353 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 4970> (DF)
17:00:08.219765 10.0.0.2.6000 > 10.0.0.7.65508: S 6581671:6581671(0) ack 2255666353 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 6 4970> (DF)
17:00:10.923185 10.0.0.2.6000 > 10.0.0.7.65508: S 6581671:6581671(0) ack 2255666353 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 11 4981> (DF)
17:00:14.218984 10.0.0.2.6000 > 10.0.0.7.65508: S 6581671:6581671(0) ack 2255666353 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 18 4981> (DF)

setkey -D -P on 10.0.0.2 for 10.0.0.7:

10.0.0.7[any] 10.0.0.2[any] any
        in ipsec
        esp/transport//require
        spid=6 seq=1 pid=533
        refcnt=5
10.0.0.2[any] 10.0.0.7[any] any
        out ipsec
        esp/transport//require
        spid=5 seq=0 pid=533
        refcnt=5

As I understand tcpdump, I should NOT be seeing anything, as the packets
tcpdump sees should be protocol ESP, not protocol TCP. So why is the
macppc sending unencrypted ACKs?

/etc/rc.d/ipsec reload "cured" the problem.
>How-To-Repeat:
	I have seen this before.
	Not sure. Have X clients log into an X server with the connection
covered by ESP. Reboot X client machine.
>Fix:

	Not sure. I suspect that the problem is that the old IPsec policy
got tied to the X server listening socket, so that new connections
started with the wrong policy.
>Release-Note:
>Audit-Trail:
>Unformatted: