On Sat, Oct 20, 2007 at 08:08:57AM -0400, Greg Troxel wrote:
> 
> So you are running wireshark on windows, and it is getting packets after
> they have come out of ESP (somehow)?  You could also take a netbsd
> laptop and watch the wire traffic, and I think that would be helpful.
> 

It would be useful but, unfortunately, I think that the opportunity
has passed in this case.  I turned off the ESP fragmentation on the
server side (in racoon) and whipped up a vbscript that sets the MTU on
the VPN virtual interface to stop oversized UDP packets from the
client happening.  The combination of both of these seems to have
worked around the problem.

> 
> I do not understand the word "tcp fragment".  It would help if you could
> post wireshark decode, or describe precisely what this means.
> 

Here is the bit from tcp dump:

22:16:39.453531 IP (tos 0x0, ttl 127, id 7021, offset 0, flags [DF], proto TCP (6), length 40) 192.168.2.254.ms-wbt-server > 192.168.169.129.capioverlan: ., cksum 0x92fa (correct), ack 2108 win 64917
22:16:39.770892 IP (tos 0x0, ttl 127, id 7022, offset 0, flags [+], proto TCP (6), length 540) 192.168.1.253.65145 > 192.168.169.129.capioverlan: . 4220967112:4220967612(500) ack 1262729909 win 65535
22:16:39.771000 IP (tos 0x0, ttl 127, id 7022, offset 520, flags [none], proto TCP (6), length 56) 192.168.1.253 > 192.168.169.129: tcp
22:16:39.771041 arp who-has 192.168.1.253 tell 192.168.169.129
22:16:39.771105 arp reply 192.168.1.253 is-at bb:bb:bb:bb:bb:00 (oui Unknown)
22:16:39.771113 IP (tos 0x0, ttl 128, id 1254, offset 0, flags [none], proto TCP (6), length 40) 192.168.169.129.capioverlan > 192.168.1.253.65145: R, cksum 0x742a (correct), 1262729909:1262729909(0) win 0
2

> What size is this packet?  Is it a single IP packet with a tcp segment
> in it, that's 1500 bytes, or at least somewhat large?
> 

The packet was 540 bytes, this was what the ESP fragment size was set
to.

> Is the only thing wrong with the packet that the source address is
> wrong?  Do the sequence number and ack fields match the last
> apparently-good packet?
>

Yes, they appear to.
 
> 
> OK - now I think I understand what you are seeing.  So the real question
> is where these packets came from.  They more or less have to been in
> ESP, or they could not have made it across the Internet.
> 

Yes, that is correct.

> 
> I suggest that you monitor everywhere you possibly can; I doubt anyone
> can figure this out without more data.
> 

That is going to be a problem now - my client has something that works
for them, they are not going to be very happy with me fiddling with it
more.  If I get a chance I will try setting up a test rig and try to
reproduce the error.

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."