RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1492501 - Reboot or 'systemctl stop ipsec' brings down _ethernet_ interfaces on _both_ ends of ipv4 ipsec tunnel !!!
Summary: Reboot or 'systemctl stop ipsec' brings down _ethernet_ interfaces on _both_ ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreswan
Version: 7.4
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Paul Wouters
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-17 23:26 UTC by Petr_P
Modified: 2018-04-10 17:24 UTC (History)
6 users (show)

Fixed In Version: libreswan-3.23-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 17:23:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
config files, commented log files (9.74 KB, application/zip)
2017-09-17 23:26 UTC, Petr_P 		no flags Details
patch to updown to prevent removing native IP from interface (5.35 KB, patch)
2017-09-19 19:10 UTC, Paul Wouters 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0932 0 None None None 2018-04-10 17:24:11 UTC

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
Note You need to log in before you can comment on or make changes to this bug.