Sorry for the delay after asking you to be more clear.

Do you have static NAT port forwarding on the server side to make this
work?  That seems not to be the issue.

  send a packet that is larger than the esp_frag size on the IPSEC
  tunnel (standard in racoon.conf is 554 bytes) then what I see on the
  XP client is tcp fragments directed at 192.168.168.100 from
  192.168.1.253.  The XP client rejects these fragments because they are
  out of state and the connection to the remote target server eventually
  fails because it is stalled.

This is what I don't understand.  The packets arriving at the XP machine
should be ESP (in UDP probably), and if I understand "esp fragmentation"
propertly those will be IP fragments, and the set of IP fragments will
once reassembled have a TCP segment as payload.  Can you observe the
packets arriving at the XP machine after they have been taken out of ESP?

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?

  Now, I do NAT the 192.168.2.0/24 net to 192.168.1.253 on the NetBSD
  rasvpn box but I don't think that really should be an issue because I
  think that I should never be getting tcp frags sent to the tunnel end
  point (192.168.168.100) by anything.

Presumably the nat only happens to packets not intended for remote VPN
space.


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?