netdev - Re: [PATCH RFC 0/1] xfrm: dst lookup doesn't account for fwmark

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jul 2016 07:20:13 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Doug Applegate <doug.applegate@...il.com>
CC:	<netdev@...r.kernel.org>, Herbert Xu <herbert@...dor.apana.org.au>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH RFC 0/1] xfrm: dst lookup doesn't account for fwmark

On Fri, Jul 22, 2016 at 03:50:30PM -0600, Doug Applegate wrote:
> I ran into an issue trying to route outgoing ipsec traffic from an
> ipsec responder hub that uses fwmark to route out a specific
> interface. The fwmark points to a route table that contains a default
> route out a specific interface.  The fwmark is applied based on
> incoming interface of incoming traffic. I noticed that the mark was
> not being used when doing a route lookup. Is there any reason why this
> is? If not does this patch look reasonable? I just followed similar
> logic to how TOS was being used before route-lookup. I've only tested
> on an earlier kernel (3.14) and it works. Thanks!
> 
> Here's an example:
> 
> The ipsec policy is simple, just a tunnel from 192.168.0.0/24 <-->
> 192.168.1.0/24 the ipsec hub is at 35.0.0.1 but when traffic is being
> responded too, instead of the expected interface (eth2) we end it out
> a different interface (eth0)
> 
> route table:
> # ip rule list
> 0: from all lookup local
> 32766: from all lookup main
> 32767: from all lookup default
> 40000: from all fwmark 0x2 lookup 3
> 40000: from all fwmark 0x4 lookup 4
> 50000: from all lookup 3
> 
> # ip route
> 25.0.0.0/30 dev eth0  src 25.0.0.1
> 35.0.0.0/30 dev eth2  src 35.0.0.1
> 192.168.1.0/24 dev lan1  src 192.168.1.1
> 
> # ip route list table 4
> default via 35.0.0.2 dev eth2 onlink
> # ip route list table 3
> default via 25.0.0.2 dev eth0 onlink

Can you provide some more information about your usecase?
Mapping between interfaces and IP addresses, policies
and states would be good.

Btw. why do you need to insert the routes as 'onlink'?
This disables some checks if this route is valid.