Project

General

Profile

Issue #3116

farp plugin claims any IPv4 address

Added by Noel Kuntze 4 months ago. Updated 4 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.8.0
Resolution:

Description

I just experienced the failure of the farp plugin in which it sends ARP responses for any ARP request it receives.
In my case, I have an XFRM interface with a correspondingly linked CHILD_SA. The TS was 0.0.0.0/0 == 0.0.0.0/0.
Version was 5.8.0, kernel 4.19.57.

History

#1 Updated by Tobias Brunner 4 months ago

  • Status changed from New to Feedback

That's by design. The documentation doesn't explicitly mention it, but the behavior is not limited to virtual IPs. The plugin basically responds to ARP request for any IPs in the negotiated remote traffic selectors. With virtual IPs that automatically only covers those, as documented, but with 0.0.0.0/0 you obviously get the described behavior.

#2 Updated by Noel Kuntze 4 months ago

I see. I'm not the first one to be surprised by this (I remember at least two occasions on IRC and on on Twitter). I'd expect the farp plugin to only cover assigned virtual IP addresses and never any IP address (0.0.0.0/0). In the best case, 0.0.0.0/0 should never be covered or at least there should be a switch for it. It's just not the default behavior that I'd expect from strongSwan.

#3 Updated by Tobias Brunner 4 months ago

I'd expect the farp plugin to only cover assigned virtual IP addresses and never any IP address (0.0.0.0/0).

I guess we could just limit the behavior to /32 traffic selectors by default (perhaps with an option to also handle any other TS, as there are use cases for this, see e.g. #250-2), but that would change the plugin's current behavior (although, as noted, it isn't documented specifically that larger TS are covered). We could also add an option that allows restricting the plugin to certain named connections (without changing the default behavior if the option is not set, there actually is a very old patch that adds that, see the farp-enable branch).

#4 Updated by Noel Kuntze 4 months ago

I suggest just not adding TS' with value 0.0.0.0/0 in the list of subnets for which ARP responses are to be faked.

Also available in: Atom PDF