mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jarkko Oranen <oranenj@iki.fi>
To: linux-kernel@vger.kernel.org
Subject: Linux router responds to any ARP query when iproute2 xfrm policies are configured for an IPSec tunnel. What's going on?
Date: Thu, 16 Jan 2020 20:25:37 +0200	[thread overview]
Message-ID: <4efb35fb-d2ee-49e7-8c7d-e8bab315ca60@iki.fi> (raw)

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

             reply	other threads:[~2020-01-16 18:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 18:25 Jarkko Oranen [this message]
2020-01-17 16:50 ` (Solved) " Jarkko Oranen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4efb35fb-d2ee-49e7-8c7d-e8bab315ca60@iki.fi \
    --to=oranenj@iki.fi \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®