All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Rasmussen <jeff.rasmussen@gmail.com>
To: netfilter@lists.netfilter.org
Subject: Re: FTP and IPSEC
Date: Thu, 7 Jul 2005 18:18:32 +0000 (UTC)	[thread overview]
Message-ID: <loom.20050707T201352-299@post.gmane.org> (raw)
In-Reply-To: 57F9959B46E0FA4D8BA88AEDFBE582909ED0@pxtbenexd01.pxt.primeexalia.com


Gary W. Smith <gary <at> primeexalia.com> writes:

> 
> Any ideas?
> 
> ________________________________
> 
> From: netfilter-bounces <at> lists.netfilter.org on behalf of Gary W. Smith
> Sent: Tue 6/28/2005 10:06 AM
> To: netfilter <at> lists.netfilter.org
> Subject: FTP and IPSEC
> 
> This is a follow up to a former problem, but unreleated.
> 
> I have two networks conencted via IPSEC.  On each side of the network I have
client servers that have
> SNAT/DNAT to the internet.  Everything seems to work well under ISPEC except
ftp.  Here is what I found.
> 
> >From location A, a workstation without a static external IP address on the
10.0.10.x can FTP anywhere on
> the net without problems but CANNOT ftp to a machine at location B using it's
internal 10.0.50.x IP.  This
> same workstation CAN ftp without restriction to it's external alias for the
same machine at location B
> using it's external IP 199.199.199.x
> 
> If I remove ip_nat_ftp and ip_conntrack_ftp it seems to work fine.  But the
problem is now that we cannot ftp
> externally from that location.  Both locations have ip_nat_ftp loaded but it
doesn't seem to matter.
> 
> When we had a pptp connection between the two locations we didn't have this
problem.  It only seems to happen
> with IPSEC. 
> 
> Is there a workaround for this or is there a way to tell ip_nat_ftp to ignore
a particular IP range?
> 
> Gary Smith
> 
> 

I'm seeing this same problem under the new Debian Sarge release.

I've upgraded from Debian Woody to Sarge and now am using a 2.6.8
kernel with Openswan and Shorewall.  The VPN tunnel works great for
all other traffic except ftp.  I keep getting the error messages below.

kernel: FTP_NAT: partial packet 2087393185/21 in 787/863
kernel: FTP_NAT: partial packet 2087393185/21 in 788/844
kernel: FTP_NAT: partial packet 2087393185/21 in 789/849
kernel: FTP_NAT: partial packet 2087393185/21 in 790/838

I have both ip_ftp_nat and ip_conntrack_ftp loaded.  I am using
one-to-one NAT (same as before) to translate the foreign network to a
local ip address.

I can log into the ftp server but when I try to list the directory it
fails in either active or passive modes.  The last communication with
the ftp server requests the active ports to use.

I've seen two links on the web, one that says that their is a conflict
between IPSEC and iptables.  The other that had a firewall rule on the
other end of the tunnel that was preventing the connection.

http://lists.shorewall.net/pipermail/shorewall-users/2004-June/012969.html
http://msgs.securepoint.com/cgi-bin/get/netfilter-0506/123.html

I'll try taking out the modules ip_ftp_nat and ip_conntrack_ftp to see if that
has the same behavior.

Jeff Rasmussen
GPG public key 0x9686C12F




  reply	other threads:[~2005-07-07 18:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-01 17:12 FTP and IPSEC Gary W. Smith
2005-07-07 18:18 ` Jeff Rasmussen [this message]
2005-07-07 18:42   ` Jeff Rasmussen
  -- strict thread matches above, loose matches on Subject: below --
2005-06-28 17:06 Gary W. Smith

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=loom.20050707T201352-299@post.gmane.org \
    --to=jeff.rasmussen@gmail.com \
    --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.