From: Stephen Frost <sfrost@snowman.net>
To: Patrick McHardy <kaber@trash.net>,
Netfilter Development Mailinglist
<netfilter-devel@lists.netfilter.org>
Subject: Re: Netfilter+IPsec patches
Date: Tue, 17 Aug 2004 22:40:25 -0400 [thread overview]
Message-ID: <20040818024025.GC21419@ns.snowman.net> (raw)
In-Reply-To: <20040527044613.GC24464@samad.com.au>
[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]
* Alexander Samad (alex@samad.com.au) wrote:
> On Thu, May 27, 2004 at 02:56:46AM +0200, Patrick McHardy wrote:
> > Please give some more details on the configuration, like:
> >
> > Are you using NAT ?
> > Are you marking the packets in the mangle table ?
> > Are the packets forwarded when they get out of the tunnel ?
> >
> > When you see the packets in the INPUT chain, does their source- and
> > destination address match your policy ?
> I did some futher testing, I was in NAT-T mode, when I removed the
> nat'ing it started to work.
I've run into a rather annoying problem. I'm not sure if it's due to
the IPSEC patches, but I have some suspicion that it is. Basically the
story goes like this:
I've got a bunch of network cards in my gateway, in this example we're
concerned w/ 3 of them- two connections to the internet, one internal.
For this to work I have to have source-based routing working (which it
used to, back when I was using 2.4). It appears to still work fine for
connections which are *not* NAT'd. For connections which are NAT'd it
goes like this:
eth0 - internet1 (has the 'default' route going out it)
eth1 - internet2 (has a seperate route table w/ a default route)
eth2 - internal
SYN comes in on eth0, NAT'd, goes out eth2, SYN+ACK comes back, that
gets NAT'd and goes out eth0. All's happy there.
SYN comes in on eth1, NAT'd, goes out eth2, SYN+ACK comes back, that
gets NAT'd to the eth1 address but then gets sent out *eth0* instead.
pings (which aren't NAT'd) to the eth1 address work fine. So do
traceroute's (again, not NAT'd). If NAT'ing is turned off and the
machine accepts connections directly then TCP connections also work
fine.
Policy-based routing is in effect, and is working for things which are
not NAT'd. Things which are NAT'd appear to be going out the main
table's default route though instead of being properly routed.
This is using 2.6.7 w/ recent (week-old) CVS iptables/pom-ng, the
IPSEC patches and some others (though *not* the new conntrack code).
Thoughts?
Thanks,
Stephen
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-08-18 2:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-26 3:35 Netfilter+IPsec patches Alexander Samad
2004-05-27 0:56 ` Patrick McHardy
2004-05-27 4:46 ` Alexander Samad
2004-08-18 2:40 ` Stephen Frost [this message]
2004-08-18 2:48 ` Stephen Frost
2004-08-21 15:30 ` Patrick McHardy
2004-08-18 3:28 ` Philip Craig
2004-08-18 3:45 ` Stephen Frost
2004-08-18 4:05 ` Alexander Samad
2004-08-18 4:31 ` Philip Craig
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=20040818024025.GC21419@ns.snowman.net \
--to=sfrost@snowman.net \
--cc=kaber@trash.net \
--cc=netfilter-devel@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.