From: Jens Taprogge <jlt_lk@shamrock.dyndns.org>
To: Patrick McHardy <kaber@trash.net>
Cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org,
netfilter@lists.netfilter.org
Subject: Re: 2.6.16-rc3 panic related to IP Forwarding and/or Netfilter
Date: Fri, 17 Feb 2006 00:29:14 +0100 [thread overview]
Message-ID: <20060216232913.GA16197@ranger.taprogge.wh> (raw)
In-Reply-To: <43F4E183.2020508@trash.net>
On Thu, Feb 16, 2006 at 09:33:07PM +0100, Patrick McHardy wrote:
> Jens Taprogge wrote:
> > The two patches fix the panic. However routing still does not quite
> > work.
> >
> > My setup consits of two masquerading gateways with local adresses
> > 192.168.1.128 (2.6.15.1) and 192.168.3.11 (2.6.16-rc3 + patches). They
> > connect the two local networks through an IPSEC tunnel. With the exact
> > same setup that previously (192.168.3.11 running 2.6.13) worked I can
> > now only reach from 192.168.1.0/24 to 192.168.3.0/24 and not the other
> > way around:
> >
> > Pinging from 192.168.1.128 I am getting:
> > $ ping 192.168.3.15
> > PING 192.168.3.15 (192.168.3.15): 56 data bytes
> > 64 bytes from 192.168.3.15: icmp_seq=0 ttl=63 time=127.9 ms
> >
> > On the other hand pinging from 192.168.3.11 I am getting timeouts.
> >
> > This is even the case if I set the nat POSTROUTING rule to:
> > $ iptables -t mangle -I PREROUTING -p esp -j MARK --set-mark 111
> > $ iptables -t nat -F POSTROUTING
> > $ iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.3.0/24 \
> > -m mark ! --mark 111 -j MASQUERADE
> >
> > on both sides of the tunnel which should disable masquerading for IPSEC
> > packages.
> >
> > However the tunnel works as soon as I completly disable masquerading.
>
> 2.6.16-rc includes patches for proper netfilter IPsec handling. Packets
> will now go through the chains once in plain text and once encrypted,
> so I guess you're masquerading the packets that should go through the
> tunnel to an address that doesn't match the policy anymore and they
> are therefore not handled by IPsec (this is also the case my patches
> fixed). So you need to make sure you don't have any SNAT rules that
> change the unencrypted packets to an address not included in the policy.
Thanks. That pointed me in the right direction. After excluding the
plain-text IPSec traffic from masquerading things work again.
Best Regards
Jens Taprogge
next prev parent reply other threads:[~2006-02-16 23:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-16 0:10 Jens Taprogge
2006-02-16 0:20 ` Patrick McHardy
2006-02-16 14:44 ` Jens Taprogge
2006-02-16 20:33 ` Patrick McHardy
2006-02-16 23:29 ` Jens Taprogge [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-02-14 17:34 Jens Taprogge
2006-02-15 6:52 ` Patrick McHardy
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=20060216232913.GA16197@ranger.taprogge.wh \
--to=jlt_lk@shamrock.dyndns.org \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome