farp plugin claims any IPv4 address
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.
#1 Updated by Tobias Brunner about 1 year 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 about 1 year 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 about 1 year 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).
#5 Updated by Tobias Brunner 10 months ago
- Tracker changed from Issue to Bug
- Target version set to 5.8.2
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.
I pushed such a change to the 3116-farp-filter branch. By the way, an interesting alternative approach might be to combine this with the enumeration of local subnets (which is also used by the bypass-lan plugin) so we could accept 0.0.0.0/0 as remote TS but would then ignore all ARP requests for IP addresses in locally connected subnets.