Linux Netfilter discussions
 help / color / mirror / Atom feed
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 ?


  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