Bug 1492501

Summary: Reboot or 'systemctl stop ipsec' brings down _ethernet_ interfaces on _both_ ends of ipv4 ipsec tunnel !!!
Product: Red Hat Enterprise Linux 7 Reporter: Petr_P <papun.dekl>
Component: libreswanAssignee: Paul Wouters <pwouters>
Status: CLOSED ERRATA QA Contact: Ondrej Moriš <omoris>
Severity: high Docs Contact:
Priority: high    
Version: 7.4CC: lmiksik, mgrepl, mthacker, omoris, pwouters, rh-bugzilla
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: libreswan-3.23-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 17:23:40 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:
Attachments:
Description Flags
config files, commented log files
none
patch to updown to prevent removing native IP from interface none

Description Petr_P 2017-09-17 23:26:23 UTC
Created attachment 1327088 [details]
config files, commented log files

Description of problem: 'systemctl stop ipsec' brings down _ethernet_ interfaces on _both_ ends of ipv4 ipsec tunnel, hence machines go offline but system is still alive as my watchdog script eventually reboots machines on both ends and ipsec tunnel is properly rebuilt after some time. It is really painful for it also happens during reboot of client machine, so simple reboot shuts down ethernet interfaces on both ends and therefore causes downtime of ipsec hub.


Version-Release number of selected component (if applicable): CentOS 7.4.1708 libreswan-3.20-3.el7.x86_64


How reproducible: always


Steps to Reproduce: Enter 'systemctl stop ipsec' or 'ipsec stop' or 'systemctl restart ipsec' during live ipv4 ipsec connection configured according attached files.


Actual results: systems on _both_ sides of ipsec tunnel are offline because their ethernet interfaces are down, ipsec tunnel is down and worst of all - ipsec hub is offline


Expected results: both systems online, both ethernet interfaces up, ipsec tunnel up and running just like it was in CentOS 7.3


Additional info: Disabling selinux has no effect. Machines have ipv6 disabled in kernel (see attached files for exact configurations and logs). Identically configured CentOS 7.3 clients run just fine.

Comment 2 Paul Wouters 2017-09-19 14:07:28 UTC
sourceip= should only be used when you have multiple IP addresses (eg multiple interfaces or being assigned an IP by the remote endpoint)

Remove leftsourceip= / rightsourceip= from your configuration

Comment 3 Paul Wouters 2017-09-19 19:09:07 UTC
I've attached a patch that fixes this.

This will be fixed in the next update.

Comment 4 Paul Wouters 2017-09-19 19:10:05 UTC
Created attachment 1328136 [details]
patch to updown to prevent removing native IP from interface

patch to updown to prevent removing native IP from interface

Comment 5 Petr_P 2017-09-26 14:21:43 UTC
Removing 'leftsourceip' and 'rightsourceip' from our configuration files solved the issue. It's running without any problems for one week now. Thanks a lot. (I haven't tested the patch)

Comment 6 Enrico Scholz 2017-12-06 10:40:46 UTC
upstream says it has been fixed (https://github.com/libreswan/libreswan/issues/142) by checking whether ip is used in a route.

Can this be please backported?

Comment 7 Paul Wouters 2017-12-07 16:47:20 UTC
(In reply to Enrico Scholz from comment #6)
> upstream says it has been fixed
> (https://github.com/libreswan/libreswan/issues/142) by checking whether ip
> is used in a route.
> 
> Can this be please backported?

backported to what? It will be fixed in rhel-7.5. If you need it to be fixed elsewhere, please open a new bug with request?

Comment 8 Enrico Scholz 2017-12-07 22:51:34 UTC
(In reply to Paul Wouters from comment #7)
> 
> backported to what?

Backported to libreswan which is shipped in RHEL 7.4.  This is a critical bug and a major regression.

Comment 13 Ondrej Moriš 2018-01-18 21:08:17 UTC
This is really tricky to reproduce. I have leftsourceip and rightsourceip configured on both server and client. Both server and client have only IPv4 address. Connection is established and then service is stopped. But nothing unexpected happens - in particular, no interface removal. Am I missing something obvious? Any hints to hit the bug?

Comment 14 Paul Wouters 2018-01-19 14:54:37 UTC
try a connection with:

left=1.2.3.4
right=5.6.7.8
leftsubnet=1.2.3.0/24
rightsubnet=5.6.7.0/24
leftsourceip=1.2.3.4
rightsourceip=5.6.7.8

this might need a 3 machine setup with a router in the middle

Comment 15 Ondrej Moriš 2018-01-25 17:22:52 UTC
(In reply to Paul Wouters from comment #14)
> try a connection with:
> 
> left=1.2.3.4
> right=5.6.7.8
> leftsubnet=1.2.3.0/24
> rightsubnet=5.6.7.0/24
> leftsourceip=1.2.3.4
> rightsourceip=5.6.7.8
> 
> this might need a 3 machine setup with a router in the middle

After all, it can reproduced with just two nodes using aforementioned configuration. Interface is not removed, it is its address what disappears and only on the side initiating connection. But I can imagine that more complex setup might lead to removing addresses on both sides. Also, it can be reproduced with libreswan-3.20-3.el7 but not with 3.15-2.el7_1 and hence it looks like a regression brought in by rebasing to 3.20. With 3.23 problem disappears, addresses are not removed.

Comment 16 Paul Wouters 2018-01-25 22:00:33 UTC
3.23 adds addresses on the loopback interface and marks them with scope 50. On --down actions, only scope 50 addresses are ever deleted.

Comment 20 errata-xmlrpc 2018-04-10 17:23:40 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0932