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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dae35070-bb8b-c110-f398-7431c243c87@ssi.bg>
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>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ