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.
I can confirm that farp is still loaded by default, disastrous consequences included.
Can you please check whether this is also dangerous on RHEL8 or newer? Would XFRM interface on newer kernels prevent this issue?
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.
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.