From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: netfilter@lists.netfilter.org
Subject: Re: Questions re iproute2, netfilter, and locally sourced packets
Date: Sat, 13 May 2006 12:15:21 +0200 [thread overview]
Message-ID: <4465B1B9.2000208@plouf.fr.eu.org> (raw)
In-Reply-To: <446576D0.2050407@aut.ac.nz>
Hello,
Ian Batterbee a écrit :
[...]
> So to achieve this, I set up another routing table, added a name for it
> into /etc/iproute2/rt_tables, added an "ip rule from [HostA] lookup
> vpn", and in the script that brings the tunnel up, routes are added for
> my work's netblocks via the ppp link to the vpn route table. This much
> all works.
> In the same script, I enable masquerading on the ppp interface. This
> appears not to work, because if I sniff from a machine on the other side
> of the tunnel (ie, at work), packets emerging from it still have their
> original IP addresses from my local subnet on them
This is a rather known issue. Iptables's MASQUERADE may not work (may it
work ?) when combined with source address based routing policy. If I
understood correctly the reason is the MASQUERADE code uses a kernel
output routing function to determine the apparent source address, but
this function does not use the original source address (why would it, as
its purpose is to find out the source address to use ?), so the ip rule
does not trigger and the main routing table is used. A workaround is to
set the apparent source address explicitly with SNAT instead of
MASQUERADE. However, unlike MASQUERADE, SNAT assumes the output
interface is static and won't clean up the conntrack/NAT table when the
PPP interface goes down, but this is not a problem if the interface
always gets the same address.
> To make things more complicated, not only is Host A allowed to route via
> the tunnel, but packets sourced from the linux router itself should also
> be allowed to go that way (or to put it another way, everything but host
> B and Host C should be allowed to use the tunnel).
>
> The trouble is, while I can allow packets from the linux router by
> adding: "ip rule add prior 50 lookup vpn" (which obviously allows
> everything to use the tunnel), I can't figure out how to specifically
> allow locally generated packets without allowing everything
> unconditionally.
What about using MARK in the mangle OUTPUT chain and fwmark in ip rule ?
next prev parent reply other threads:[~2006-05-13 10:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-13 6:04 Questions re iproute2, netfilter, and locally sourced packets Ian Batterbee
2006-05-13 10:15 ` Pascal Hambourg [this message]
2006-05-18 13:55 ` Menno Smits
-- strict thread matches above, loose matches on Subject: below --
2006-05-14 19:01 Ian Batterbee
2006-05-14 21:11 ` Pascal Hambourg
[not found] <200605150359.k4F3xG1O006127@horuhoru-3.aut.ac.nz>
2006-05-15 6:31 ` Ian Batterbee
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=4465B1B9.2000208@plouf.fr.eu.org \
--to=pascal.mail@plouf.fr.eu.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