Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
+++ This bug was initially created as a clone of Bug #1127605 +++
+++ This bug was initially created as a clone of Bug #771461 +++
Description of problem:
openswan Ikev2 implementation does not correctly process traffic selectors narrowed to TCP
Version-Release number of selected component (if applicable):
libreswan-3.8-6.el7_0
How reproducible:
Always
Steps to Reproduce:
1. Configure libreswan like following:
/etc/ipsec.conf:
INITIATOR:
config setup
protostack=netkey
plutodebug=all
nat_traversal=yes
plutostderrlog=/var/log/test.log
conn test
left=$INITIATOR
right=$RESPONDER
authby=secret
phase2=esp
auto=add
ikev2=insist
RESPONDER:
config setup
protostack=netkey
plutodebug=all
nat_traversal=yes
plutostderrlog=/var/log/test.log
conn test
left=$INITIATOR
right=$RESPONDER
authby=secret
phase2=esp
auto=add
ikev2=insist
leftprotoport=tcp
rightprotoport=tcp
2. both sides: service ipsec (re)start; initiator: ipsec auto --up test
3. Check ISAKMP, IPSEC SAs (should be alive): ipsec auto --status
Actual results:
133 "test" #1: STATE_PARENT_I1: initiate
133 "test" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
134 "test" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_128 integ=sha1_96 prf=oakley_sha group=modp2048}
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 20s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
031 "test" #2: max number of retransmissions (20) reached STATE_PARENT_I2. Possible authentication failure: no acceptable response to our first encrypted message
000 "test" #2: starting keying attempt 1 of an unlimited number, but releasing whack
133 "test" #11: STATE_PARENT_I1: initiate, replacing #1
133 "test" #11: STATE_PARENT_I1: sent v2I1, expected v2R1
:: [ PASS ] :: Running 'ipsec auto --up test' (Expected 0, got 0)
whack: is Pluto running? connect() for "/var/run/pluto/pluto.ctl" failed (111 Connection refused)
:: [ PASS ] :: Running 'ipsec auto --status' (Expected 0, got 0)
:: [ PASS ] :: Running 'ip xfrm state' (Expected 0, got 0)
whack: is Pluto running? connect() for "/var/run/pluto/pluto.ctl" failed (111 Connection refused)
:: [ FAIL ] :: ISAKMP SA should be alive (Expected 0, got 1)
whack: is Pluto running? connect() for "/var/run/pluto/pluto.ctl" failed (111 Connection refused)
Expected results:
Additional info:
--- Additional comment from Paul Wouters on 2014-10-24 00:13:54 EDT ---
the configuration is missing narrowing=yes in the connection configuration. Please try again?
See also the 7 or so narrowing test case configurations we have at
https://github.com/libreswan/libreswan/tree/master/testing/pluto
--- Additional comment from Aleš Mareček on 2014-12-05 08:26:30 EST ---
Same as there: https://bugzilla.redhat.com/show_bug.cgi?id=1125913#c4
--- Additional comment from Paul Wouters on 2015-01-28 12:25:44 EST ---
Our test case for this passes: https://github.com/libreswan/libreswan/tree/master/testing/pluto/ikev2-allow-narrow-06
the responder also needs narrowing=yes in its configuration.
--- Additional comment from Aleš Mareček on 2015-02-08 12:03:48 EST ---
narrowing=yes didn't help.
--- Additional comment from Aleš Mareček on 2015-02-08 12:04:07 EST ---
--- Additional comment from Paul Wouters on 2015-02-26 23:25:44 EST ---
can you provide logs and config of your latest attempt?
--- Additional comment from Paul Wouters on 2016-01-21 11:26:07 EST ---
ping? Can we either close this bug or confirm it? To confirm it, I need to see the configuration files used.
--- Additional comment from Jaroslav Aster on 2016-03-23 13:36:03 EDT ---
Hi Paul,
it still fails. Tested on libreswan-3.15-5.el7_1. Openswan, on the same test, passes.
Server:
config setup
protostack=netkey
plutodebug=all
nat_traversal=yes
plutostderrlog=/var/log/pluto.log
conn test
type=tunnel
left=<CLIENT_IP>
right=<SERVER_IP>
authby=secret
phase2=esp
auto=add
ikev2=insist
Client:
config setup
protostack=netkey
plutodebug=all
nat_traversal=yes
plutostderrlog=/var/log/pluto.log
conn test
type=tunnel
left=<CLIENT_IP>
right=<SERVER_IP>
authby=secret
phase2=esp
auto=add
ikev2=insist
leftprotoport=tcp
rightprotoport=tcp
S:
# service ipsec start
C:
# service ipsec start
# ipsec auto --up test
002 "test" #1: initiating v2 parent SA
133 "test" #1: STATE_PARENT_I1: initiate
133 "test" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
134 "test" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_gcm_16_256 integ=n/a prf=sha group=MODP2048}
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 500ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 1000ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 2000ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 4000ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 8000ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 16000ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
^C
--- Additional comment from Jaroslav Aster on 2016-03-30 08:20:39 EDT ---
There is no change with adding option narrowing=yes on both site - server, client, but if I add
leftprotoport=tcp
rightprotoport=tcp
to the server conf instead of client conf, then it works.
yes, the specification allows one to NARROW a request, not to WIDEN a request.
So the client sends 0/0 and the server narrows it to tcp. You cannot do it the other way around.
See: https://tools.ietf.org/html/rfc7296#section-2.9