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  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 <>
To:	Doug Applegate <>
CC:	<>, Herbert Xu <>,
	"David S. Miller" <>
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 <-->
> the ipsec hub is at 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
> dev eth0  src
> dev eth2  src
> dev lan1  src
> # ip route list table 4
> default via dev eth2 onlink
> # ip route list table 3
> default via 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.

Powered by blists - more mailing lists