mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Linux router responds to any ARP query when iproute2 xfrm policies are configured for an IPSec tunnel. What's going on?
@ 2020-01-16 18:25 Jarkko Oranen
  2020-01-17 16:50 ` (Solved) " Jarkko Oranen
  0 siblings, 1 reply; 2+ messages in thread
From: Jarkko Oranen @ 2020-01-16 18:25 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: (Solved) Linux router responds to any ARP query when iproute2 xfrm policies are configured for an IPSec tunnel. What's going on?
  2020-01-16 18:25 Linux router responds to any ARP query when iproute2 xfrm policies are configured for an IPSec tunnel. What's going on? Jarkko Oranen
@ 2020-01-17 16:50 ` Jarkko Oranen
  0 siblings, 0 replies; 2+ messages in thread
From: Jarkko Oranen @ 2020-01-17 16:50 UTC (permalink / raw)
  To: linux-kernel

Hi,



hopefully I got the In-Reply-To header right.



Turns out that while I thought I had disabled charon's fake-arp plugin, 
it was silently loading configuration from /etc/strongswan/charon I 
didn't expect it to load and despite the plugin being enabled, it made 
no indication that this is the case. I'll leave this here for Google in 
case someone else stubs their toe on this.



Sorry for the noise.


--

Jarkko

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-01-17 16:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-16 18:25 Linux router responds to any ARP query when iproute2 xfrm policies are configured for an IPSec tunnel. What's going on? Jarkko Oranen
2020-01-17 16:50 ` (Solved) " Jarkko Oranen

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®