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

Message-ID: <CACwzwmXfY3rpWfaspveT3JvumhPXYrMCH3TUwM1WNgEFKZ_t4A@mail.gmail.com>
Date:	Fri, 22 Jul 2016 15:50:30 -0600
From:	Doug Applegate <doug.applegate@...il.com>
To:	netdev@...r.kernel.org,
	Steffen Klassert <steffen.klassert@...unet.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	"David S. Miller" <davem@...emloft.net>
Subject: [PATCH RFC 0/1] xfrm: dst lookup doesn't account for fwmark

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

I noticed this in netfilter trace, traffic matches the ipsec policy:
[   85.910365] TRACE: mangle:PREROUTING:rule:4 IN=lan1 OUT=
MAC=00:30:44:ff:b6:43:42:17:87:41:3c:eb:08:00 SRC=192.168.1.5
DST=192.168.0.5 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=35127 PROTO=ICMP
TYPE=0 CODE=0 ID=15069 SEQ=1 MARK=0x4
[   85.911895] TRACE: mangle:FORWARD:rule:2 IN=lan1 ***OUT=eth0***
MAC=00:30:44:ff:b6:43:42:17:87:41:3c:eb:08:00 SRC=192.168.1.5
DST=192.168.0.5 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=35127 PROTO=ICMP
TYPE=0 CODE=0 ID=15069 SEQ=1 MARK=0x4