IPSec tcp session stalling ( me too ) ...

[Volker]

Matthew,

thanks for your reply. Glad to hear that I'm not the only one
experiencing this problem. So the problem is IPSec + firewall but not
related to pf or ipfw. Is it IPSec + bandwidth management??

I've tried a different test setup and just pushed a bunch of
(/dev/random) data over a tcp connection through the IPSec tunnel using:

	%gnetcat 10.128.1.6 49001 /dev/random
at host B (10.128.6.1) and did

	%netcat -l -p 49001 > netcat.out
on host A (10.128.1.6).

After the file 'netcat.out' reached the file size of 66.108 bytes
(around the same size as the scp transfer aborts every time) the tcp
stream has been closed with:

host B: write(net): Operation not permitted
host A: read(net): Connection reset by peer

I've managed to get a tcpdump of the gif interfaces on both hosts. Both
files are attached to this message (hostA.cap and hostB.cap). These
files viewed by ethereal gives a nice look at the tcp flow. There you
can see hostB sends three RST packets at the end (for whatever reason).

The only thing I've seen (looking a bit ugly) is that hostA answers
packets (ACK) before the data payload is being received. At least that's
the way tcpdump has seen these packets. That should be related to
priorisation of ACK packets using ALTQ.

Is anybody else here with deep TCP + IPSec knowledge able to get a look
into this? Any known issues? Is there anything I might also check out?
Is there a 64k limit with IPSec? :(

Thanks,

Volker


On 2005-10-22 19:33, Matthew Grooms wrote:
> Volker,
> 
>      I have noticed the same problem. In my case, it only seems to
> happen when the traffic is being forwarded across interfaces and pf or
> ipfw is enabled. I use purely IPSEC so I would agree that GRE isn't the
> problem. This behavior is 100% reproducible for me. If traffic is
> forwarded from the host providing the ESP protection or if the firewall
> package is disabled, the problem goes away.
> 
>      Just some data points. I don't recall seeing this ever happen on
> 4.x + ipfw. I experienced this on early 5.x + ipfw, late 5.x + pf and
> 6.x + pf. I believe the ipfw versions I tested were prior to the pfil
> hooks conversion.
> 
> For example ...
> 
> NODE 1 sftp client
> NODE 2 sftp server
> IPSEC policy requires ESP protection from NODE 1 or VPN A to NODE 2
> 
> NODE 1 ------ VPN A ===== VPN B ----- NODE 2
> 
> 1) NODE 1 <-> NODE 2 sftp via IPSEC pf enabled, traffic stalls
> 2) NODE 1 <-> NODE 2 sftp via IPSEC pf disabled, no problems
> 3) VPN A  <-> NODE 2 sftp via IPSEC pf enabled, no problems
> 
> NOTE : TCP protocol is irrelevant. Haven't tried UDP.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hostB.cap
Type: application/octet-stream
Size: 9168 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20051022/0f3c39cc/hostB.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hostA.cap
Type: application/octet-stream
Size: 9084 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20051022/0f3c39cc/hostA.obj