linux-kernel - Linux router responds to any ARP query when iproute2 xfrm policies are configured for an IPSec tunnel. What's going on?

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: <4efb35fb-d2ee-49e7-8c7d-e8bab315ca60@iki.fi>
Date:   Thu, 16 Jan 2020 20:25:37 +0200
From:   Jarkko Oranen <oranenj@....fi>
To:     linux-kernel@...r.kernel.org
Subject: Linux router responds to any ARP query when iproute2 xfrm policies
 are configured for an IPSec tunnel. What's going on?

Hi,

First of all, I'm not currently subscribed to LKML, so please CC any 
replies.

I recently debugged a DHCP client which refused to accept a lease, and 
noticed that my router seems to reply to ARP requests for any IP 
address, apparently causing the client to think it was receiving a 
duplicate IP.

After some debugging, I learned that my router will respond to any ARP 
query if the IP falls within the traffic selector I'm using for my xfrm 
interface-based IPSec VPN. For example:

$ arping 1.1.1.1

ARPING 1.1.1.1 from 10.21.1.10 enp7s0

Unicast reply from 1.1.1.1 [00:0D:B9:4B:07:C1]  1.449ms

I tried changing the various ARP-related sysctls, but they had no effect 
on this behaviour. It stops immediately if I kill the IPSec tunnel and 
the xfrm policies are removed.

The xfrm interface is created simply with
   ip link add st0 type xfrm dev eth0 if_id 1
and 10/8 is routed to it, though this doesn't seem to matter.

When the IPSec tunnel is up and running, it configures xfrm policies 
like so:

src 0.0.0.0/0 dst 0.0.0.0/0

	dir out priority 399999 ptype main

	tmpl src <my-ip> dst <remote-ip>

		proto esp spi 0xc5a3f611 reqid 1 mode tunnel

	if_id 0x1

src 0.0.0.0/0 dst 0.0.0.0/0

	dir fwd priority 399999 ptype main

	tmpl src <remote-ip> dst <my-ip>

		proto esp reqid 1 mode tunnel

	if_id 0x1

src 0.0.0.0/0 dst 0.0.0.0/0

	dir in priority 399999 ptype main

	tmpl src <remote-ip> dst <my-ip>

		proto esp reqid 1 mode tunnel

	if_id 0x1

src 0.0.0.0/0 dst 0.0.0.0/0

	socket in priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

	socket out priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

	socket in priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

	socket out priority 0 ptype main

src ::/0 dst ::/0

	socket in priority 0 ptype main

src ::/0 dst ::/0

	socket out priority 0 ptype main

src ::/0 dst ::/0

	socket in priority 0 ptype main

src ::/0 dst ::/0

	socket out priority 0 ptype main

The traffic selector affects what ARP requests the router responds to, 
so if I change it to 10.0.0.0/8, it will respond to any ARP request for 
IPs in that range.

This is happening on Alpine Linux running kernel version 5.4.12-1-lts.

Is this expected behaviour? I would appreciate some pointers.

--
Jarkko Oranen