All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eliezer Croitor" <ngtech1ltd@gmail.com>
To: 'Marcin Szewczyk' <marcin.szewczyk@wodny.org>
Cc: 'Fatih USTA' <fatihusta86@gmail.com>,
	'Netfilter Users Mailing list' <netfilter@vger.kernel.org>
Subject: RE: re-routing multicast pkts after mangle table marking
Date: Wed, 2 Dec 2020 17:57:25 +0200	[thread overview]
Message-ID: <002e01d6c8c3$d4fa4e00$7eeeea00$@gmail.com> (raw)
In-Reply-To: <X8eKYjtPSINtYYnl@flatwhite>

Thanks for taking the time to reply.

I have seen a similar "issue" with outgoing traffic generated locally.
From what I understand the diagram:
*
https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.sv
g

Doesn't talk about locally generated traffic..
I can try to regenerate this issue to understand it better.

There is a big difference in the linux kernel routing cache since the time
of the test...
If you want to re-produce this issue you can try to use iperf3 instead of
iperf.
iperf3 -c 224.1.1.1 -u  -b 10k

Can you create a test lab using netns ?
You can see a fully automated example lab that I wrote at:
https://github.com/elico/mwan-nft-lb-example/blob/main/run-lab.sh

Or another lab examples can be seen at Vincent blog posts github repository:
https://vincent.bernat.ch/en/blog/2018-route-based-vpn-wireguard

I don't understand if there is something to verify at all..

Thanks,
Eliezer

----
Eliezer Croitoru
Tech Support
Mobile: +972-5-28704261
Email: ngtech1ltd@gmail.com

-----Original Message-----
From: Marcin Szewczyk <marcin.szewczyk@wodny.org> 
Sent: Wednesday, December 2, 2020 2:37 PM
To: Eliezer Croitor <ngtech1ltd@gmail.com>
Cc: 'Fatih USTA' <fatihusta86@gmail.com>; 'Netfilter Users Mailing list'
<netfilter@vger.kernel.org>
Subject: Re: re-routing multicast pkts after mangle table marking

On Wed, Dec 02, 2020 at 02:10:00PM +0200, Eliezer Croitor wrote:
> On Tue, Dec 01, 2020 at 07:49:43PM +0100, Marcin Szewczyk wrote:
> > Brian Aanderud on 23 Mar 2015 wrote:
> > > What must I do to get the multicast frames routed out a 'different'
> > > interface from the default one after applying a fwmark in iptables the
> > > routing table?  I am able to do this with unicast with a combination
> > > of 'ip rule', 'ip route' to a different table, and iptables to apply a
> > > 'mark'.  But, the marked multicast frames never seem to follow the
> > > other routing table's routes.
> > > [...]
> > 
> > I've stumbled upon the same problem as the one discussed over 5 years
> > ago (with no answer) on this mailing list[1], ie. locally generated
> > multicast and broadcast traffic do not seem to follow policy routing
> > when it is constructed using `iptables --set-mark` and `ip rule fwmark`.

> Just wondering, how can I reproduce this issue on my local network?

The configuration is actually in the message you quoted[1]. You do not
need a network adhering to any specific configuration to reproduce it.
It's a local phenomenon.

> First a broadcast address cannot be "routed" elsewhere then a
> connected network, there is no real "routing" so to speak.

Here routing is limited to the local machine. `ip rule dport` actually
produces positive results so there is a way to force broadcast traffic
to adhere to local routing rules even though the traffic is not going to
be routed on the next layer 3 hop.

In general -- broadcast and multicast traffic adheres to rules in any
table not guarded by the fwmark criterion.

> I do not know how the kernel looks at it but I assume it can only be sent
> towards a connected device such as:
> * ethernet
> * tunnel(these which support broadcast)

I am using my wifi interface but one can reproduce the experiments I
mentioned with a veth device as well:

    ip link add ve1 type veth peer ve2

> Also I am missing some of the thread emails so, What kernel are we talking
> about?
> Let say Debian/Ubuntu/RHEL/CentOS , what version? Etc..

I mentioned Debian Jessie (kernel 4.9) and Debian Buster (kernel 4.19).

> Reproducing is important to understand what the issue is.

As I mentioned -- configuration is in the quoted email[1] and in the
original email[2] (not mine) from 2015.

[1]: https://marc.info/?l=netfilter&m=160690828202259
[2]: https://marc.info/?l=netfilter&m=142714167809246

-- 
Marcin Szewczyk
http://wodny.org


  reply	other threads:[~2020-12-02 15:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-23 20:14 re-routing multicast pkts after mangle table marking Brian Aanderud
2020-12-01 18:49 ` Marcin Szewczyk
     [not found]   ` <CAF4tN+_YNz+0iCQzW7Fd+P5ZkDkU5g95Jv5fdHPNcqhzWtOOng@mail.gmail.com>
     [not found]     ` <X8bE6GMR6U37cfH/@flatwhite>
     [not found]       ` <CAN_K0LS+U95rxmhCtiE3sX_hdjEQySnV1HBB9sF1qrrVAz0n-w@mail.gmail.com>
2020-12-02 11:23         ` Marcin Szewczyk
2020-12-02 12:10           ` Eliezer Croitor
2020-12-02 12:36             ` Marcin Szewczyk
2020-12-02 15:57               ` Eliezer Croitor [this message]
2020-12-02 16:12                 ` Marcin Szewczyk
2020-12-02 16:30                   ` Fatih USTA
2020-12-02 17:03                     ` Marcin Szewczyk
2020-12-02 17:35                   ` Eliezer Croitor
2020-12-02 18:04                     ` Marcin Szewczyk
2020-12-03  8:39                       ` Fatih USTA

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='002e01d6c8c3$d4fa4e00$7eeeea00$@gmail.com' \
    --to=ngtech1ltd@gmail.com \
    --cc=fatihusta86@gmail.com \
    --cc=marcin.szewczyk@wodny.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.