From: Stephen Touset <stephen@touset.org>
To: netfilter@lists.netfilter.org
Subject: Problems w/ Linux firewall and Windows VPN
Date: Thu, 01 Jan 2004 20:36:20 -0500 [thread overview]
Message-ID: <1073007380.11132.3.camel@localhost> (raw)
[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]
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>
"What do you mean, 'Veritas is acting screwy'? Veritas is the shit!"
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2004-01-02 1:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-02 1:36 Stephen Touset [this message]
2004-01-02 2:29 ` Problems w/ Linux firewall and Windows VPN Stephen Touset
2004-01-02 3:21 ` Stephen Touset
[not found] <E131E9F1848D0148813EAF06A846608F01C677ED@w2ks-e2k.iconos.be>
2004-01-02 21:36 ` Stephen Touset
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1073007380.11132.3.camel@localhost \
--to=stephen@touset.org \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.