Skip to contentSkip to conversation

New: wrong source addr of UDP packets when using policy routing

Bugme-new Andrew Morton 4 participants 7 messages Jun 16, 2010 – Jun 22, 2010 1 message not in the archive

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Andrew Morton

author
#1 lore raw
In reply to a message not in the archive
Quoted 7 lines · On Tue, 15 Jun 2010 15:14:43 GMT [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=16216

           Summary: wrong source addr of UDP packets when using policy
                    routing
           Product: Networking
           Version: 2.5
    Kernel Version: 2.6.24.7

The reporter has confirmed that this issue persistes in 2.6.34.

Quoted 48 lines

Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: No

When policy routing is used, UDP packets have wrong source address. Source addr is probably taken from looking up routing table (main) to given destination instead of being set just after POSTROUTING, looking up cache.

This how it looks like doing simple netcat test:
(tcpdump is run on aa.aa.47.90)
16:38:02.053053 IP aa.aa.47.67.32826 > aa.aa.47.90.660: UDP, length 8 16:38:05.660394 IP bb.bbb.241.62.660 > aa.aa.47.67.32826: UDP, length 8

aa.aa.47.90 have specific setup having 3 routing tables: main, 10, 20 and all of them have default gateway. bb.bbb.241.62 is an addr of outgoing interface of default route from main table.
If a packet cames from specific interface
its being stored to ipset and when packet is going to be sent out of the box its being marked in mangle OUTPUT matching specific ipset:

### mangle PREROUTING ###
fw="iptables -t mangle -A PREROUTING"
$fw -i vlan0.13 -j SET --add-set gw10 src
$fw -i lan2 -j SET --add-set gw20 src

### mangle OUTPUT ###
fw="iptables -t mangle -A OUTPUT"
$fw -m set --set gw10 dst -j MARK --set-mark 10
$fw -m set --set gw10 dst -j ACCEPT
$fw -m set --set gw20 dst -j MARK --set-mark 20
$fw -m set --set gw20 dst -j ACCEPT

% ip rule show
32764: from all fwmark 0x14 lookup 20
32765: from all fwmark 0xa lookup 10

Problem was noticed for UDP packets (openvpn connections are not working). Other non connection oriented protocols might be affected too. TCP (as connection oriented protocol) works just fine.

#2 lore raw
Quoted 5 lines · Andrew Morton
Quoted 2 lines · On Tue, 15 Jun 2010 15:14:43 GMT [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=16216

Quoted 52 lines
Quoted 6 lines
           Summary: wrong source addr of UDP packets when using policy
                    routing
           Product: Networking
           Version: 2.5
    Kernel Version: 2.6.24.7

The reporter has confirmed that this issue persistes in 2.6.34.

Quoted 42 lines

Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: No

When policy routing is used, UDP packets have wrong source address. Source addr is probably taken from looking up routing table (main) to given destination instead of being set just after POSTROUTING, looking up cache.

This how it looks like doing simple netcat test:
(tcpdump is run on aa.aa.47.90)
16:38:02.053053 IP aa.aa.47.67.32826 > aa.aa.47.90.660: UDP, length 8 16:38:05.660394 IP bb.bbb.241.62.660 > aa.aa.47.67.32826: UDP, length 8

aa.aa.47.90 have specific setup having 3 routing tables: main, 10, 20
and all of them have default gateway. bb.bbb.241.62 is an addr of outgoing interface of default route from main table. If a packet cames from specific interface
its being stored to ipset and when packet is going to be sent out of the box
its being marked in mangle OUTPUT matching specific ipset:

### mangle PREROUTING ###
fw="iptables -t mangle -A PREROUTING"
$fw -i vlan0.13 -j SET --add-set gw10 src
$fw -i lan2 -j SET --add-set gw20 src

### mangle OUTPUT ###
fw="iptables -t mangle -A OUTPUT"
$fw -m set --set gw10 dst -j MARK --set-mark 10
$fw -m set --set gw10 dst -j ACCEPT
$fw -m set --set gw20 dst -j MARK --set-mark 20
$fw -m set --set gw20 dst -j ACCEPT

% ip rule show
32764: from all fwmark 0x14 lookup 20
32765: from all fwmark 0xa lookup 10

This is know behaviour, fwmarks don't work for source address selection since before the source address is chosen, you don't even have a packet which could be marked.

Acked-by
#3 lore raw
Quoted 3 lines · Patrick McHardy

This is know behaviour, fwmarks don't work for source address selection since before the source address is chosen, you don't even have a packet which could be marked.

We know have sk->sk_mark routing (socket based), so we might change sk->sk_mark with appropriate iptables target when one packet is received... not very clean but worth to mention...

commit 914a9ab386a288d0f22252fc268ecbc048cdcbd5

Author: Atis Elsts <[email protected]>
Date:   Thu Oct 1 15:16:49 2009 -0700

net: Use sk_mark for routing lookup in more places

This patch against v2.6.31 adds support for route lookup using sk_mark in some more places. The benefits from this patch are the following. First, SO_MARK option now has effect on UDP sockets too.
Second, ip_queue_xmit() and inet_sk_rebuild_header() could fail to do routing lookup correctly if TCP sockets with SO_MARK were used.

Signed-off-by Atis Elsts <[email protected]>
Acked-by Eric Dumazet <[email protected]>
#4 lore raw
Quoted 12 lines · Eric Dumazet
Quoted 4 lines · Patrick McHardy

This is know behaviour, fwmarks don't work for source address selection since before the source address is chosen, you don't even have a packet which could be marked.

We know have sk->sk_mark routing (socket based), so we might change sk->sk_mark with appropriate iptables target when one packet is received... not very clean but worth to mention...

That would still be too late. The proper way would be to have the application set the socket mark.

#5 lore raw

Okey. Did you people came into any conclusions?
Is there a patch I can test?

I tried to find 914a9ab386a288d0f22252fc268ecbc048cdcbd5 in few stable trees but was unable to.

---------- Original message ----------

From: Patrick McHardy <[email protected]>
To: Eric Dumazet <[email protected]>
Cc: Andrew Morton <[email protected]>, [email protected],
[email protected], [email protected], [email protected]
Subject: Re: [Bugme-new] [Bug 16216] New: wrong source addr of UDP packets when
using policy routing
Date: Wed, 16 Jun 2010 19:43:16 +0200
Message-ID: <[email protected]>

Quoted 12 lines · Eric Dumazet
Quoted 4 lines · Patrick McHardy

This is know behaviour, fwmarks don't work for source address selection since before the source address is chosen, you don't even have a packet which could be marked.

We know have sk->sk_mark routing (socket based), so we might change sk->sk_mark with appropriate iptables target when one packet is received... not very clean but worth to mention...

That would still be too late. The proper way would be to have the application set the socket mark.

#6 lore raw
Quoted 2 lines · Unknown

Okey. Did you people came into any conclusions?
Is there a patch I can test?

As I said, its known and expected behaviour and there's nothing netfilter can do about it. You could patch your application to use the SO_MARK socket option to set the socket mark.

#7 lore raw

Hmm. This is not an option.

Okey, thx for info. Seems its time for some hack & slash ;)

---------- Original message ----------

From: Patrick McHardy <[email protected]>
To: Unknown <[email protected]>
Cc: Eric Dumazet <[email protected]>,
Andrew Morton <[email protected]>, [email protected], [email protected], [email protected]
Subject: Re: [Bugme-new] [Bug 16216] New: wrong source addr of UDP packets when
using policy routing
Date: Tue, 22 Jun 2010 08:09:44 +0200
Message-ID: <[email protected]>

Quoted 2 lines · Unknown

Okey. Did you people came into any conclusions?
Is there a patch I can test?

As I said, its known and expected behaviour and there's nothing netfilter can do about it. You could patch your application to use the SO_MARK socket option to set the socket mark.