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.
hostB.cap
Description: Binary data
hostA.cap
Description: Binary data
_______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"