Project

General

Profile

Issue #250

farp plugin doesn't fake arp for non-installed but routed tunnels

Added by Brian T almost 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Category:
libcharon
Affected version:
5.0.1
Resolution:

Description

When a tunnel definition is defined with "auto=route" and has not yet been initialized, farp does not fake arp for IP addresses behind the tunnel. The result of this is that the tunnel will never be brought up unless the gateway itself tries to send traffic across or machines behind the gateway specifically route packets via the gateway (like a static route, but that defeats the point of the farp plugin).

History

#1 Updated by Tobias Brunner almost 8 years ago

  • Status changed from New to Feedback

The farp plugin, by its current definition, only fakes ARP packets for IP addresses that were assigned as virtual IP addresses to clients. This is mainly useful if these virtual IP addresses are assigned from the same subnet that is behind the gateway (e.g. in combination with the dhcp plugin).

How exactly does your use case look like? Do you use the same subnet on both ends of the tunnel? What do you have configured as left|rightsubnet on both sides?

Keep in mind that most hosts will not send an ARP request if they are able to determine (based on their own IP address and subnet mask) that the destination address is not on the local network, instead they will simply send it to the default gateway. In that case a static route for the remote subnet of the tunnel (via strongSwan gateway) might be configured on the default gateway (then only one route has to be configured).

#2 Updated by Brian T almost 8 years ago

So according to my observations and the 4.6.X changelog (http://wiki.strongswan.org/projects/strongswan/wiki/Changelog46), "The farp plugin sends ARP responses for any tunneled address, not only virtual IPs."

I have two home networks that are both behind their own consumer-grade router and in each network I have a Linux server running various things (Samba, Apache, MySQL, etc, and now strongSwan). The addressing scheme for site A is 192.168.1.X and the scheme for B is 192.168.2.X The subnet mask on each is 255.255.252.0 (deliberately done to take advantage of 4.6.3's farp) and the server that is running strongSwan does not have any routes pointed to it. My leftsubnet is 192.168.1.0/24 and my rightsubnet is 192.168.2.0/24

When my tunnel is up, farp will respond to the other side's IP addresses and life is great. If the tunnel is down (auto=routed), then farp doesn't reply at all.

#3 Updated by Tobias Brunner almost 8 years ago

So according to my observations and the 4.6.X changelog (http://wiki.strongswan.org/projects/strongswan/wiki/Changelog46), "The farp plugin sends ARP responses for any tunneled address, not only virtual IPs."

You are right, I forgot about that. The plugin basically checks if the addresses of an ARP request match the traffic selectors of any CHILD_SA.

If the tunnel is down (auto=routed), then farp doesn't reply at all.

That's correct. It only uses the child_updown event to collect the information about tunneled subnets (i.e. it will only know about established CHILD_SAs). Unfortunately, there are currently no hooks for the plugin to learn about routed connections.

Until the listener interface is extended you might want to keep the connection established (something like: auto=start, dpdaction=restart, closeaction=restart, keyingtries=%forever, reauth=no).

#4 Updated by Andreas Steffen over 7 years ago

  • Tracker changed from Bug to Issue
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner

Also available in: Atom PDF