On Mon, Oct 15, 2007 at 09:25:18PM +0930, Brett Lymn wrote:
> 
> The problem I have is that if a packet gets larger than the esp
> fragment setting in racoon.conf (esp_frag) then I start seeing
> problems.  I have done a packet capture on the Windows client when it
> is connecting to a machine on the other side of the vpn server - I can
> see the packets flow between the client and the other machine fine
> until the other machine decides to send a packet that is larger than
> than esp_frag.  At this point I see some tcp fragments that originate
> from the external facing address of the vpn server directed to the vpn
> client tunnel end point.  These packets are rejected because they are
> out of state.  Of course, at this point, the connection through to the
> other machine stalls and eventually dies.
> 

I had a private email saying that I have been a bit obtuse.  I was
trying to avoid a horrible ascii diagram but...

                  +----------------+
                  | XP Client      |
                  | vpn tunnel ip  |
                  | 192.168.168.100|
                  +----------------+
                           | XP Client IP: 192.168.3.3
                           |
                           | 192.168.3.2
                      +---------+
                      | router  |
                      | (nat)   |
                      +---------+
                           |
                           // Internet
                           |
                      +----------+
                      | client   |
                      | router   |
                      +----------+
                           | 192.168.1.254
                           |
                           | 192.168.1.253
                   +-----------------+
                   | NetBSD RASVPN   |
                   |    server       |
                   +-----------------+
                           | 192.168.2.253
                           |
                           | 192.168.2.10
                   +-----------------+
                   | Remote target   |
                   |    server       |
                   +-----------------+


Apologies for the horrible ascii art.  Now, what I want to do is make
a connection from the XP client to the remote target server
(192.168.2.10).  If the packets are small, they go from the XP client
down the IPSEC tunnel (192.168.168.100) and pop out on the rasvpn
server and get routed to the remote target server and the reverse
happens fine.  If the remote target server (192.168.2.10) decides to
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.

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.


> 
> I also perform a mss clamp on the packets going out.  I tried playing
> with net.inet.ipsec.dfbit - it was set at 2, setting it to 1 seemed to
> have no effect.
> 
> I have bumped esp_frag up high enough that it is currently not causing
> an issue for my client but I would like to find a more correct fix for
> the problem.
> 
> -- 
> 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."

-- 
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."