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  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, 11 Sep 2014 13:54:01 +0200
From:	Steffen Klassert <>
To:	Konstantinos Kolelis <>
CC:	<>, <>,
	<>, <>,
	<>, <>,
Subject: Re: [BUG REPORT]  Unencrypted packets after SNAT, allthough
 IPSEC-Policies are present

On Wed, Sep 10, 2014 at 07:26:53PM +0200, Konstantinos Kolelis wrote:
> Hi all,
> i' ve observed a problem with xfrm lookups, SNAT, blackhole route and
> missing SAs.
> The problem occures with all Kernels above 3.6.x and might has to do
> with the changes in
> ip4_blackhole_route() function in net/route.c.

Thanks for the report!

Is kernel v3.6 the first kernel with this issue? It seems that
we have this problem already longer, at least if my analysis
is correct.

> Let say you have two network interfaces:
> eth0 with ip
> and
> eth1 with ip
> and you have done the following configuration:
> iptables -t nat -A POSTROUTING -s -j SNAT --to-source
> and
> ip xfrm policy add dir out  src dst tmpl proto esp
> src dst mode tunnel
> with the following routes:
> default via dev eth0  proto static
> dev eth0  proto kernel  scope link  src
> dev eth1  proto kernel  scope link  src
> If for what ever reason IPSEC-SAs can not be established, maybe because
> is down,
> the traffic comming from will leave unencrypted the
> external (eth0) interface.

I can reproduce it with SNAT and MASQUERADE. Looks like this was
introduced back in 2011 with git commit 2774c131 ("xfrm: Handle
blackhole route creation via afinfo.").

Before that commit, xfrm_lookup() and __xfrm_lookup() returned
an error if we have a matching policy but no states. The route
lookup functions used __xfrm_lookup() and generated a blackhole
route if __xfrm_lookup() returned -EREMOTE. All other functions
used xfrm_lookup() which returned -EAGAIN. This was treated as
as an error and the packet was dropped immediately.

After this commit all callers to xfrm_lookup() rely that
dst_output() is called afterwards. This seems to be not the
case, at least when postrouting nat is used.

Maybe we should go back to let only the route lookup functions
genarate a blackhole route. Everyone else should better drop
the packets immediately.

I'll try to do a patch.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists