Bug 1488421

Summary:	Loading farp module by default may have very destructive consequences
Product:	[Fedora] Fedora EPEL	Reporter:	Rolf Fokkens <rolf>
Component:	strongswan	Assignee:	Petr Menšík <pemensik>
Status:	CLOSED EOL	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	epel7	CC:	bugzilla, code, pemensik
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
URL:	https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#VTI-Devices-on-Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-07-09 02:12:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rolf Fokkens 2017-09-05 11:14:56 UTC

Description of problem:

When using strongswan the NIC generates ARP replies for any ARP request that is received by the NIC when the ipsec connetion becomes active, (potentially) bringing a network to its knees.

Disabling (not loading) the farp module resolves the matter.

The issue is probably the result of both using VTI and having farp loaded. More details below.

It may be best to NOT load farp by default, so only when needed.

Version-Release number of selected component (if applicable):
strongswan-5.5.3-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Configure VTI in ipsec.conf (e.g. mark=42)
2. Configure leftsubnet=0.0.0.0/0 and rightsubnet=0.0.0.0/0 in ipsec.conf
3. Fire up strongswan
4. See your network breaking down

Actual results:
Network DOS attack by faking ARP replies

Expected results:
Working ipsec tunnel without side effects

Additional info:
VTI setupt is doneaccording to: https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#VTI-Devices-on-Linux

No mentiones of farp risks are on this page.

Comment 1 bugzilla 2019-05-16 14:36:49 UTC

I can confirm that farp is still loaded by default, disastrous consequences included.

Comment 2 Petr Menšík 2021-11-11 01:03:43 UTC

Can you please check whether this is also dangerous on RHEL8 or newer? Would XFRM interface on newer kernels prevent this issue?

Comment 3 Rolf Fokkens 2023-05-07 11:26:58 UTC

Answering this requires testing, but rather not by breaking my network again. Not knowing how to easily test this, I won't. For me personally the issue is known, and I can work around it.

Comment 4 Troy Dawson 2024-07-09 02:12:03 UTC

EPEL 7 entered end-of-life (EOL) status on 2024-06-30.\n\nEPEL 7 is no longer maintained, which means that it\nwill not receive any further security or bug fix updates.\n As a result we are closing this bug.