Linux Netfilter discussions
 help / color / mirror / Atom feed
From: John Haxby <john.haxby@oracle.com>
To: ipso@snappymail.ca
Cc: netfilter@vger.kernel.org
Subject: Re: v2.6.16 to v2.6.38 breaks routing?
Date: Mon, 12 Sep 2011 10:24:11 +0100	[thread overview]
Message-ID: <4E6DCFBB.6060401@oracle.com> (raw)
In-Reply-To: <4E6D3F01.4060807@snappymail.ca>

On 12/09/11 00:06, Mike wrote:
> I'm in the process of upgrading an older Linux router from Mandriva
> running kernel v2.6.16 to Ubuntu running v2.6.38 kernel, however my
> moderately complex firewall/routing script doesn't quite work the same
> way on the newer system. The basic idea is that I have three routes to
> three different ISPs, and one to the internal network. I then mark
> packets to go out a specific ISP depending on the type of traffic.
> This all works fine if the packets are initiated from the router
> itself or from a computer on the intenral network with packets
> destined out the default ISP, but it fails completely if the packets
> are initiated from a computer on the internal network destined out an
> non-default route.
>
> What I don't understand is I diff'd the routing tables and all
> iptables commands they are virtually identical between the two
> servers, yet the newer server doesn't work as expected. 

You might be running afoul of the change in behaviour of rp_filter that
happened around 2.6.32.

Previously (as in your 2.6.16 kernel) setting
net.ipv4.conf.default.rp_filter=1 in /etc/sysctl.conf (or wherever your
distro puts that file would give you what is now termed "loose reverse
path filtering".  Now, however, that value gives you strict reverse path
filtering and 2 gives you loose reverse path filtering.

Strict reverse path filtering discards incoming packets whose source
address would not be routed to the interface that the packets originated
from; loose reverse path filtering merely checks that the source address
is routable.   In Documentation/networking/ip-sysctl.txt is says that
you might want loose reverse path filtering for complicated routing set
ups (like yours).

In some cases you can mess with the routing tables dynamically so that a
source address appearing on an interface will cause outgoing packets for
that address to use that interface.   I haven't really looked into this
yet: setting rp_filter=2 was enough to get over my immediate problem,
although I would still like to get rid of the asymmetric routing at some
stage.   If you do go down that path though, I would be very interested
to see what you do.

jch

  parent reply	other threads:[~2011-09-12  9:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-11 23:06 v2.6.16 to v2.6.38 breaks routing? Mike
2011-09-12  4:13 ` v2.6.16 to v2.6.38 breaks routing? - Simplified Mike
2011-09-12  9:24 ` John Haxby [this message]
2011-09-12 14:59   ` v2.6.16 to v2.6.38 breaks routing? Mike

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=4E6DCFBB.6060401@oracle.com \
    --to=john.haxby@oracle.com \
    --cc=ipso@snappymail.ca \
    --cc=netfilter@vger.kernel.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