Project

General

Profile

Issue #3610

farp plugin conflicts with DHCP service

Added by Tom Hsiung about 1 month ago. Updated 29 days ago.

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

Description

Hi,

Looking on the surface, the cause of this conflict is the farp plugin. OK. Both StrongSwan and ISC-DHCP were deployed on a same machine. And the DHCP use a pool to assign IP addresses to regular clients. Also there is a fixed IP assignment rule for one client which use site2site strongSwan encapsulation.

So, if I load the farp plugin, those regular clients can retrieve IP addresses from ISC-DHCP server. However, for the client that will go through the site2site tunnel, it failed. The macOS system noticed me that the predefined fixed IP address had already been taken, even if it was not in reality. And during this moment, if I ran the command of `ipsec stop`, the client immediately successfully retrieve the predefined IP address.

Tom

History

#1 Updated by Tobias Brunner 29 days ago

  • Status changed from New to Feedback

The farp plugin responds with ARP responses to requests for any IP address that is listed in the remote traffic selector of any established CHILD_SA (since 5.8.2 0.0.0.0/0 is ignored) if the source IP if the request is listed in the local traffic selector. So make sure that there are no conflicts.

#2 Updated by Tom Hsiung 29 days ago

Thank you for your respond, Tobias.

According to your description. It seems that issue was caused by the fact that I have assigned a fixed IP address to my client based on its real MAC address, configured in the DHCP server. However, when farp plugin is enabled, the DHCP server (affected by the strongSwan farp plugin when the IPsec tunnel is estalished) will assign IP addresses based on the virtual MAC addresses, which are different from the clients' real physical MAC addresses. So, the real MAC defined in the DHCP server and the virtual MAC it actually used conflicted, resulting in this problem.

Above correct?

Tom

#3 Updated by Tobias Brunner 29 days ago

However, when farp plugin is enabled, the DHCP server (affected by the strongSwan farp plugin when the IPsec tunnel is estalished) will assign IP addresses based on the virtual MAC addresses

The dhcp plugin does not know the client's physical MAC address, it will always request an IP with a virtual MAC address (this has nothing to do with the farp plugin). That address is optionally based on the client's identity, which you could actually use directly instead of any MAC address as it is sent to the server too if identity_lease is enabled (there are examples for both in our regression tests). However, if the DHCP server does an ARP lookup for that IP it might detect a duplicate IP if the farp plugin responds with the server's physical MAC address. However, it will only do so once a remote traffic selector that covers that IP is negotiated with a peer (e.g. if incorrect TS are configured and negotiated with other peers, or maybe during make-before-break reauthentication, although, the dhcp plugin can't handle that properly anyway).

So, the real MAC defined in the DHCP server and the virtual MAC it actually used conflicted, resulting in this problem.

I don't see any conflict with the client's physical MAC address, unless perhaps you used the server's MAC address (which is the one with which the farp plugin answers to ARP requests) or if the client is actually in the same LAN as the VPN/DHCP server (but that will produce weird effects anyway).

Also available in: Atom PDF