Probing around more, the last packet being sent is a TCP Zero Window packet. However, the few prior packets show its window being 65535. How can its window go from 65535 to zero that quickly? On Thu, 2004-01-01 at 19:53, Stephen Touset wrote: > I've recently set up a firewall in our house, running Debian. It's using > iptables to do packet filtering. When I installed it, my mother started > having problems connecting through VPN to her company (MAPICS). The > connection starts fine, but after 5-10 minutes, it disconnects. I do not > have this problem connecting to other VPN servers (such as to my > employer) using her computer, so I know this is specific to their > system. > > Previously, we were using a Linksys router, and it worked fine. > > Now, my first idea was that the firewall was blocking a certain type of > packet, thus causing the connection to be terminated. However, running > tcpdump on the internal and external interfaces show that everything is > passing through nicely. > > Of note is that every time, right before the disconnect, their VPN > server sends a PPTP Echo-Request to her client. The response from her > client is a TCP RST, and the connection is terminated. I have verified > this repeatedly, and this is the case every time. However, there are > dozens of other times during the connection where a PPTP Echo-Request is > sent from their server, and her client responds with the correct PPTP > Echo-Reply, and they respond with a TCP ACK on that reply. In other > words, the echo handshake goes back and forth several times throughout > the connection, correctly, and at one of them her client decides not to > reply, and simply RST the connection. I've examined the packets > containing the Request from both a completed handshake and from the > terminated one, and they both appear to be identical, excluding sequence > numbers and acknowledgment numbers. > > I'm attaching packet captures from ethereal in the libpcap format--one > from the perspective of the internal interface, and one from the > external. These are pre-filtered, so they contain *all* network traffic > at the time, so I'm positive that nothing that could identify the > problem is left out. The VPN server is 208.217.85.63, and her client is > 192.168.1.102. It's over a PPTP connection, with a Windows-based VPN > server--I'm guessing Windows 2000 Server. > > If anyone could help me discover what the problem is, or point me in the > direction of someone who could, I would be *extremely* grateful. -- Stephen Touset <stephen@touset.org>
Attachment:
signature.asc
Description: This is a digitally signed message part