Bug 1345959
| Summary: | openswan - libreswan migration issues | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Ondrej Moriš <omoris> |
| Component: | libreswan | Assignee: | Paul Wouters <pwouters> |
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.8 | CC: | aheverle, bressers, cww, ebenes, jaster, jreznik, ksrot, mrogers, pwouters, salmy |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-03-21 09:06:16 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1269194, 1343211 | ||
|
Description
Ondrej Moriš
2016-06-13 13:50:28 UTC
(In reply to Ondrej Moriš from comment #0) > 1) Status of ipsec service is not preserved when updating from openswan to > libreswan. This is fixed now. Both default state and status are preserved now. However, when ipsec is restarted during upgrade to libreswan it prints the following message: Shutting down pluto IKE daemon 030 ignoring message from whack with bad magic 2003331865; should be 1869114150; Mismatched versions of userland tools and KLIPS code. > 2) Previously, ike option allowed to use so-called strict mode when IKE > algorithm started with "!", this was already obsoleted in openswan and > ignored. With libreswan this notation is no longer recognized (syntax > error). This seems not to be fixed - having ike=!<something> will produce the following error: Dec 19 17:22:09: ike string error: No alphanum. char initially found, just after "" (old_state=ST_INI) (In reply to Ondrej Moriš from comment #7) > > 2) Previously, ike option allowed to use so-called strict mode when IKE > > algorithm started with "!", this was already obsoleted in openswan and > > ignored. With libreswan this notation is no longer recognized (syntax > > error). > > This seems not to be fixed - having ike=!<something> will produce the > following error: > > Dec 19 17:22:09: ike string error: No alphanum. char initially found, just > after "" (old_state=ST_INI) I am not sure what was the decision about ike=!<something>. Could you shed some light on it Paul? Behaviour of libreswan is the same in 6.8 and 6.9 - syntax error. In openswan as far as I am trying to recall "!" character was ignored and connection was loaded. I see the following options: 1) libreswan ignores "!" and load the connection 2) libreswan fails to load connection and reports that using "!" is no longer supported 3) "!" characters are removed during openswan->libreswan update From my point of view the second option would be the best. upstream libreswan has never supported ignoring the "!". That change from openswan was part of the first libreswan release (3.0) It was already years obsolete in openswan. Currently, option 2 happens. I do not think we need to make any change to libreswan so support that very old syntax. No one should have been using it with openswan either because even for openswan when specifying an ike=/esp= line, it would be automatically "strict". Thanks Paul. Even though I imagined something more helpful than "ike string error: No alphanum. char initially found, just after """, I can see your point a) this problem will affect literally nobody, b) the rest will find parser error message in the log leading them to ike string, c) changing the parser to handle this particular error would be really odd. All in all, I consider this bug to be successfully verified now, for more details please see TJ#1642906. 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://rhn.redhat.com/errata/RHBA-2017-0575.html |