mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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