Brett Lymn <blymn@baesystems.com.au> writes:

> On Fri, Oct 19, 2007 at 04:21:31PM -0400, Greg Troxel wrote:

>> Can you observe the packets arriving at the XP machine after they
>> have been taken out of ESP?
>
> That is about all I can observe - wireshark does not seem to "see" the
> ESP traffic, I don't know why.

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.

Having captured this, and if you can snarf the key from the NetBSD box
with setkey, I think you can then decrypt the packets in tcpdump.

>> What do you mean by "out of state"?  Is there a firewall on the XP
>> machine, or are you saying that the TCP someone gets something that has
>> a sequence number that is too high, and thus doesn't send an ack?
>
> What I mean by out of state is that most of the traffic flow I can see
> is between the xp client and the remote server (192.168.168.100 <=>
> 192.168.2.10) but, suddenly, I see a couple of tcp fragments from

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

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?

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?

> 192.168.1.253 directed at 192.168.168.100, the xp machine reacts to
> these packets by sending a RST because they are not part of an
> established connection.

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.

> I didn't sniff the NetBSD side, so I can only
> speculate that a large packet came from the remote server
> (192.168.2.10) was fragmented but the fragments were not directed the
> right way.

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

>> So looking with tcpdump, I'd expect to see
>>
>> A = 1500 byte packet leaving 192.168.2.10 which is IP TCP
>>
>> 3 (presumably that's where 554 comes from) packets leaving NetBSD RASVPN
>> server, and each should be
>>
>> IP UDP ESP IP-fragment(3 parts of A)
>>
>> Does that match what you are seeing?
>
> It's difficult to say because I couldn't see the ESP traffic - all I
> can see is what looks like a normal application conversation happen
> but then it just stalls and I get the tcp fragments from a place they
> should not come from.
>
> I did turn off the esp_frag in racoon.conf on the rasvpn server, that
> seemed to make things work for me.  On one of my client's machines I
> had to also adjust the MTU on the vpn virtual interface which, also,
> is very strange because I was able to vpn and work fine from his
> internet connection.

So that means more or less that either the esp_frag implementation in
NetBSD is buggy, at least when using NAT, or the XP implementation is
buggy.

Presumably 192.168.1.253, the internet-facing address of the rasvpn box,
is used for the outer source on the IP packet containing ESP.  It is
seeming that two things could be happening (plus others):

  The NetBSD RASVPN box, when fragmenting the IP packet from
  192.168.2.10, is somehow creating IP fragments with the wrong
  (192.168.1.253) source address.

  The windows box, when taking the fragments out of ESP, is putting the
  wrong address on them before reassembly.

Reading the source, it seems esp_frag only happens for NAT-T, and I
don't see how this problem can occur.  (I'm not saying it can't be
happening, but I didn't spot a bug on reading.)

I did confirm that esp_frag is about fragmenting the IP packet before
placing it inside the outer (IP UDP ESP).

So the next step is to tcpdump on the wire, either near the XP client or
near the rasvpn box, and capture the ESP traffic, and decrypt it to see
what addresses are on the packet.