linux-kernel - Re: [PATCH net] ipv4: fix source address and gateway mismatch under multiple default gateways

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 13 Nov 2022 22:01:36 +0200 (EET)
From:   Julian Anastasov <ja@....bg>
To:     "Ziyang Xuan (William)" <william.xuanziyang@...wei.com>
cc:     netdev@...r.kernel.org, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] ipv4: fix source address and gateway mismatch under
 multiple default gateways


	Hello,

On Sat, 29 Oct 2022, Ziyang Xuan (William) wrote:

> > On Wed, 26 Oct 2022, Ziyang Xuan wrote:
> > 
> >> We found a problem that source address doesn't match with selected gateway
> >> under multiple default gateways. The reproducer is as following:
> >>
> >> Setup in client as following:
> >>
> >> $ ip link add link eth2 dev eth2.71 type vlan id 71
> >> $ ip link add link eth2 dev eth2.72 type vlan id 72
> >> $ ip addr add 192.168.71.41/24 dev eth2.71
> >> $ ip addr add 192.168.72.41/24 dev eth2.72
> >> $ ip link set eth2.71 up
> >> $ ip link set eth2.72 up
> >> $ route add -net default gw 192.168.71.1 dev eth2.71
> >> $ route add -net default gw 192.168.72.1 dev eth2.72
> > 
> > 	Second route goes to first position due to the
> > prepend operation for the route add command. That is
> > why 192.168.72.41 is selected.
> > 
> >> Add a nameserver configuration in the following file:
> >> $ cat /etc/resolv.conf
> >> nameserver 8.8.8.8
> >>
> >> Setup in peer server as following:
> >>
> >> $ ip link add link eth2 dev eth2.71 type vlan id 71
> >> $ ip link add link eth2 dev eth2.72 type vlan id 72
> >> $ ip addr add 192.168.71.1/24 dev eth2.71
> >> $ ip addr add 192.168.72.1/24 dev eth2.72
> >> $ ip link set eth2.71 up
> >> $ ip link set eth2.72 up
> >>
> >> Use the following command trigger DNS packet in client:
> >> $ ping www.baidu.com
> >>
> >> Capture packets with tcpdump in client when ping:
> >> $ tcpdump -i eth2 -vne
> >> ...
> >> 20:30:22.996044 52:54:00:20:23:a9 > 52:54:00:d2:4f:e3, ethertype 802.1Q (0x8100), length 77: vlan 71, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 25407, offset 0, flags [DF], proto UDP (17), length 59)
> >>     192.168.72.41.42666 > 8.8.8.8.domain: 58562+ A? www.baidu.com. (31)
> >> ...
> >>
> >> We get the problem that IPv4 saddr "192.168.72.41" do not match with
> >> selected VLAN device "eth2.71".
> > 
> > 	The problem could be that source address is selected
> > once and later used as source address in following routing lookups.
> > 
> > 	And your routing rules do not express the restriction that
> > both addresses can not be used for specific route. If you have
> > such restriction which is common, you should use source-specific routes:
> 
> Hi Julian,
> 
> Thank you for your quick reply.
> 
> Can we make some work to make the restriction "both addresses can not be used for specific route" in code but in consciousness?

	No good idea about this. Not sure if the new 'nexthop'
object is suitable for such policy.

Regards

--
Julian Anastasov <ja@....bg>