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 1934058 - ikeport does not work for host-to-host
Summary: ikeport does not work for host-to-host
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libreswan
Version: 8.4
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: 8.5
Assignee: Daiki Ueno
QA Contact: BaseOS QE Security Team
Khushbu Borole
URL:
Whiteboard:
Depends On: 1958968
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-02 12:00 UTC by Ondrej Moriš
Modified: 2021-11-10 01:34 UTC (History)
5 users (show)

Fixed In Version: libreswan-4.4-1.el8
Doc Type: Bug Fix
Doc Text:
.`leftikeport` and `rightikeport` options work correctly Previously, Libreswan ignored the `leftikeport` and `rightikeport` options in any host-to-host Libreswan connections. As a consequence, Libreswam used the default ports regardless of any non-default options settings. With this update, the issue is now fixed and you can use `leftikeport` and `rightikeport` connection options over the default options.
Clone Of:
Environment:
Last Closed: 2021-11-09 18:49:51 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
backport patch for libreswan 4.3 (829 bytes, patch)
2021-04-13 14:15 UTC, Paul Wouters 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Github submariner-io submariner issues 1253 0 None open libreswan fails when non standard ports are used, and Private IPS are used between two endpoints. 2021-04-12 13:57:01 UTC
Red Hat Product Errata RHBA-2021:4299 0 None None None 2021-11-09 18:50:02 UTC

Description Ondrej Moriš 2021-03-02 12:00:55 UTC 
Description of problem:

Version 4.3 of libreswan contains new ikeport feature - using leftikeport/rightikeport one case specify IKE port to use instead of default ports 500/4500. 

Unfortunately, a connection using ikeport cannot be established in host-to-host scenario.

Version-Release number of selected component (if applicable):

libreswan-4.3

How reproducible:

100%

Steps to Reproduce:

0. Enable nis_enabled selinux boolean.

1. Configure both client and server as follows:

conn test
  authby=secret
  left=<SERVER>
  right=<CLIENT>
  ikev2=insist
  leftikeport=2500
  auto=add

2. Start ipsec service

3. Initiate connection from the client (ipsec auto --up test).

Actual results:

CLIENT:

# ipsec auto --up test
181 "test" #1: initiating IKEv2 connection
181 "test" #1: sent IKE_SA_INIT request
002 "test" #1: WARNING: connection test PSK length of 9 bytes is too short for HMAC_SHA2_512 PRF in FIPS mode (32 bytes required)
182 "test" #1: sent IKE_AUTH request {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048}
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 0.5 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 1 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 2 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 4 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 8 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 16 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 32 seconds for response
031 "test" #2: STATE_PARENT_I2: 60 second timeout exceeded after 7 retransmits.  Possible authentication failure: no acceptable response to our first encrypted message
000 "test" #2: starting keying attempt 2 of an unlimited number, but releasing whack

SERVER (log): 

"test": local IKE proposals (IKE SA responder matching remote proposals):
"test":   1:IKE=AES_GCM_C_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
"test":   2:IKE=AES_GCM_C_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
"test":   3:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
"test":   4:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
"test" #1: proposal 1:IKE=AES_GCM_C_256-HMAC_SHA2_512-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_256;DH=MODP2048;DH=MODP3072;DH=MODP4096;DH=MODP8192;DH=ECP_256;DH=ECP_384;DH=ECP_521;DH=CURVE25519[first-match] 2:IKE:ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_256;DH=MODP2048;DH=MODP3072;DH=MODP4096;DH=MODP8192;DH=ECP_256;DH=ECP_384;DH=ECP_521;DH=CURVE25519 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048;DH=MODP3072;DH=MODP4096;DH=MODP8192;DH=ECP_256;DH=ECP_384;DH=ECP_521;DH=CURVE25519 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048;DH=MODP3072;DH=MODP4096;DH=MODP8192;DH=ECP_256;DH=ECP_384;DH=ECP_521;DH=CURVE25519
"test" #1: sent IKE_SA_INIT reply {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048}
"test" #1: processing decrypted IKE_AUTH request: SK{IDi,AUTH,SA,TSi,TSr}
"test" #1: IKEv2 mode peer ID is ID_IPV4_ADDR: '10.0.136.227'
"test" #1: WARNING: connection test PSK length of 9 bytes is too short for HMAC_SHA2_512 PRF in FIPS mode (32 bytes required)
"test" #1: authenticated using authby=secret
"test" #1: WARNING: connection test PSK length of 9 bytes is too short for HMAC_SHA2_512 PRF in FIPS mode (32 bytes required)
"test": local ESP/AH proposals (IKE_AUTH responder matching remote ESP/AH proposals):
"test":   1:ESP=AES_GCM_C_256-NONE-NONE-DISABLED
"test":   2:ESP=AES_GCM_C_128-NONE-NONE-DISABLED
"test":   3:ESP=AES_CBC_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-NONE-DISABLED
"test":   4:ESP=AES_CBC_128-HMAC_SHA2_512_256+HMAC_SHA2_256_128-NONE-DISABLED
"test" #2: proposal 1:ESP=AES_GCM_C_256-DISABLED SPI=739032e9 chosen from remote proposals 1:ESP:ENCR=AES_GCM_C_256;ESN=DISABLED[first-match] 2:ESP:ENCR=AES_GCM_C_128;ESN=DISABLED 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED
"test" #2: cannot install route: peer is within its client
"test" #2: encountered fatal error in state STATE_V2_IKE_AUTH_CHILD_R0
"test" #1: deleting other state #2 (STATE_V2_IKE_AUTH_CHILD_R0) aged 0.000349s and NOT sending notification
"test" #2: ERROR: netlink response for Del SA esp.739032e9.136.227 included errno 3: No such process
"test" #1: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 0.007817s and NOT sending notification
packet from 10.0.136.227:4500: IKE_AUTH message request has no corresponding IKE SA
packet from 10.0.136.227:4500: IKE_AUTH message request has no corresponding IKE SA
packet from 10.0.136.227:4500: IKE_AUTH message request has no corresponding IKE SA
packet from 10.0.136.227:4500: IKE_AUTH message request has no corresponding IKE SA
packet from 10.0.136.227:4500: IKE_AUTH message request has no corresponding IKE SA

Expected results:

Connection is established correctly.

Additional info:

subnet-to-subnet scenario seems to be working - upstream test ikev2-ikeport-02-initiator passed on RHEL-8.4 and 4.3 version of libreswan.
Comment 2 Ondrej Moriš 2021-03-02 12:35:50 UTC 
Acceptance Criteria: 

 * [gating] connection can be established when using ikeport and chosen port is actually used for IKE
Comment 3 Paul Wouters 2021-03-02 14:41:15 UTC 
Confirmed this issue. Created a new upstream test case ikev2-ikeport-06-host-to-host
Comment 4 Ondrej Moriš 2021-03-09 11:52:18 UTC 
I found issue also in tcp-remoteport. If I understand it correctly, it is a TCP counterpart of ikeport (used for UDP) and hence I will consider it as a part of this bug, I can also split it (just let me know).

Consider the following configuration:

version 2.0

config setup
 plutodebug="all"
 logappend=no
 plutostderrlog="/tmp/pluto.log"
 listen-tcp=yes
 
conn test
 authby=secret
 left=10.0.137.197
 right=10.0.138.223
 ikev2=insist
 enable-tcp=yes
 tcp-remoteport=4300

When pluto is started it seems to ignore port 4300:

000 using kernel interface: xfrm
000  
000 interface eth0 TCP [2620:52:0:88:f816:3eff:fe79:3cd2]:4500
000 interface eth0 UDP [2620:52:0:88:f816:3eff:fe79:3cd2]:500
000 interface lo TCP [::1]:4500
000 interface lo UDP [::1]:500
000 interface lo TCP 127.0.0.1:4500
000 interface lo UDP 127.0.0.1:4500
000 interface lo UDP 127.0.0.1:500
000 interface eth0 TCP 10.0.137.197:4500
000 interface eth0 UDP 10.0.137.197:4500
000 interface eth0 UDP 10.0.137.197:500

But it is listed in the connection:

000 "test": 10.0.137.197<10.0.137.197>...10.0.138.223<10.0.138.223>; unrouted; eroute owner: #0
000 "test":     oriented; my_ip=unset; their_ip=unset; my_updown=ipsec _updown;
000 "test":   xauth us:none, xauth them:none,  my_username=[any]; their_username=[any]
000 "test":   our auth:secret, their auth:secret
000 "test":   modecfg info: us:none, them:none, modecfg policy:push, dns:unset, domains:unset, cat:unset;
000 "test":   sec_label:unset;
000 "test":   ike_life: 28800s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;
000 "test":   retransmit-interval: 500ms; retransmit-timeout: 60s; iketcp:yes; iketcp-port:4300;
000 "test":   initial-contact:no; cisco-unity:no; fake-strongswan:no; send-vendorid:no; send-no-esp-tfc:no;
000 "test":   policy: IKEv2+PSK+ENCRYPT+TUNNEL+PFS+UP+IKE_FRAG_ALLOW+ESN_NO;
000 "test":   v2-auth-hash-policy: none;
000 "test":   conn_prio: 32,32; interface: eth0; metric: 0; mtu: unset; sa_prio:auto; sa_tfc:none;
000 "test":   nflog-group: unset; mark: unset; vti-iface:unset; vti-routing:no; vti-shared:no; nic-offload:auto;
000 "test":   our idtype: ID_IPV4_ADDR; our id=10.0.137.197; their idtype: ID_IPV4_ADDR; their id=10.0.138.223
000 "test":   dpd: action:hold; delay:0; timeout:0; nat-t: encaps:auto; nat_keepalive:yes; ikev1_natt:both
000 "test":   newest ISAKMP SA: #0; newest IPsec SA: #0; conn serial: $1;

However, when connection is initiated (ipsec auto --up test):

Mar  9 05:31:54.696126: "test": initiating connection 'test' with serial $1 which received a Delete/Notify but must remain up per local policy
Mar  9 05:31:54.696132: | initiate_connection_3() connection 'test' +POLICY_UP
Mar  9 05:31:54.696136: | ipsecdoi_initiate() called with sec_label 
Mar  9 05:31:54.696139: | FOR_EACH_STATE_... in find_phase1_state
Mar  9 05:31:54.696210: | newref alloc logger@0x5635e0b729d8(0->1) (in new_state() at state.c:417)
Mar  9 05:31:54.696216: | addref fd@NULL (in new_state() at state.c:418)
Mar  9 05:31:54.696220: | creating state object #2 at 0x5635e0b74498
Mar  9 05:31:54.696224: | State DB: adding IKEv2 state #2 in UNDEFINED
Mar  9 05:31:54.696231: | pstats #2 ikev2.ike started
Mar  9 05:31:54.696245: | parent state #2: UNDEFINED(ignore) => PARENT_I0(ignore)
Mar  9 05:31:54.696250: | #2.st_v2_transition NULL -> PARENT_I0->PARENT_I1 (in new_v2_ike_state() at state.c:462)
Mar  9 05:31:54.696262: | Message ID: IKE #2 initializing (IKE SA): ike.initiator.sent=0->-1 ike.initiator.recv=0->-1 ike.initiator.last_contact=0->1927.645338 ike.responder.sent=0->-1 ike.responder.recv=0->-1 ike.responder.last_contact=0->1927.645338 ike.wip.initiator=0->-1 ike.wip.responder=0->-1
Mar  9 05:31:54.696267: | orienting "test"
Mar  9 05:31:54.696275: |   left(THIS) host-address=10.0.137.197 host-port=500 ikeport=0 encap=no
Mar  9 05:31:54.696280: |   right(THAT) host-address=10.0.138.223 host-port=500 ikeport=0 encap=no
Mar  9 05:31:54.696294: |   interface endpoint [2620:52:0:88:f816:3eff:fe79:3cd2]:4500 does not match left(THIS) or right(THAT)
Mar  9 05:31:54.696301: |   interface endpoint [2620:52:0:88:f816:3eff:fe79:3cd2]:500 does not match left(THIS) or right(THAT)
Mar  9 05:31:54.696306: |   interface endpoint [::1]:4500 does not match left(THIS) or right(THAT)
Mar  9 05:31:54.696311: |   interface endpoint [::1]:500 does not match left(THIS) or right(THAT)
Mar  9 05:31:54.696316: |   interface endpoint 127.0.0.1:4500 does not match left(THIS) or right(THAT)
Mar  9 05:31:54.696321: |   interface endpoint 127.0.0.1:4500 does not match left(THIS) or right(THAT)
Mar  9 05:31:54.696326: |   interface endpoint 127.0.0.1:500 does not match left(THIS) or right(THAT)
Mar  9 05:31:54.696330: |   interface endpoint 10.0.137.197:4500 does not match left(THIS) or right(THAT)
Mar  9 05:31:54.696335: |   interface endpoint 10.0.137.197:4500 does not match left(THIS) or right(THAT)
Mar  9 05:31:54.696340: |   interface endpoint 10.0.137.197:500 matches left(THIS); orienting
Mar  9 05:31:54.696345: | in initialize_new_state with remote endpoint set to 10.0.138.223:500
Mar  9 05:31:54.696351: | TCP: forcing #2 remote endpoint port to 4300
Mar  9 05:31:54.696354: | TCP: opening socket
Mar  9 05:31:54.696383: | TCP: socket 14 connecting to other end
Mar  9 05:31:54.705279: ERROR: "test" #2: TCP: connect(14) failed. Errno 111: Connection refused
Mar  9 05:31:54.705359: | should_send_delete: no, not established
Comment 5 Paul Wouters 2021-03-09 20:55:16 UTC 
for outgoing TCP, the source port is going to be an ephemeral port. We will only know the port once we start using it. So setting a remote-tcp-port= does not cause us to listen on anything pre-emptively
Comment 6 Paul Wouters 2021-03-09 20:56:45 UTC 
Set severity and priority to low, as it is very rare to use TCP for host-to-host. It's main use case is VPN Remote Access, where you get an IP/32 <-> 0.0.0.0/0 network.
Comment 7 Ondrej Moriš 2021-03-11 09:02:49 UTC 
Acceptance Criteria:

AC1: The following upstream tests pass on RHEL in namespace-based testsuite
 - ikev2-ikeport-02-initiator
 - ikev2-ikeport-03-responder
 - ikev2-ikeport-04-rw-nat-initiator
 - ikev2-ikeport-05-rw-nat-responder

AC2: [gating] when {left,right}-ikeport option is set to arbitrary unreserved port in host-to-host scenario, IKE uses the port (both IKEv1 and IKEv2).

AC3: [gating] when tcp-remoteport option in host-to-host scenario using IKE over TCP, IKE uses that port (IKEv2 only).

Granting qa_ack+ for RHEL-8.5.0.
Comment 8 Miguel Angel Ajo 2021-04-12 13:46:01 UTC 
We are also hitting AC2 in submariner when using different than standard --ikeports:


I0412 13:36:37.140531       1 libreswan.go:368] Executing whack with args: [--psk --encrypt --name submariner-cable-kind2-172-18-0-9-0-0 --id 172.18.0.10 --host 172.18.0.10 --client 172.18.0.10/32 --ikeport 4511 --to --id 172.18.0.9 --host 172.18.0.9 --client 172.18.0.9/32 --ikeport 4502]
002 adding UDP interface eth0 172.18.0.10:4511
002 "submariner-cable-kind2-172-18-0-9-0-0": added IKEv2 connection
003 "submariner-cable-kind2-172-18-0-9-0-0": cannot install route: peer is within its client
025 "submariner-cable-kind2-172-18-0-9-0-0": could not route


This is a common case when we are trying to setup multiple endpoints on a private network: we need multiple ports (different ones) to be able
to map a single public IP to those ports/endpoints individually


Paul, can we raise priority for this bug?
Comment 9 Paul Wouters 2021-04-12 14:09:55 UTC 
hmm, I don't seem to get that error based on those arguments ?

root@thinkpad:/home/paul# ip addr show dev wlp2s0
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default qlen 1000
    link/ether 34:e1:2d:b0:08:92 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.21/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 603761sec preferred_lft 603761sec
    inet6 fd00:788d:f7e2:4782:dadc:5a46:583f:c4fc/64 scope global dynamic noprefixroute 
       valid_lft 535089sec preferred_lft 401232sec
    inet6 fe80::5067:5b7c:6387:7392/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever


root@thinkpad:/home/paul# ipsec whack --psk --encrypt --name submariner-cable-kind2-172-18-0-9-0-0 --id 192.168.0.21 --host 192.168.0.21 --client 192.168.0.21/32 --ikeport 4511 --to --id 192.168.0.13 --host 192.168.0.13 --client 192.168.0.13/32 --ikeport 4502
002 adding UDP interface wlp2s0 192.168.0.21:4511
002 "submariner-cable-kind2-172-18-0-9-0-0": added IKEv2 connection
root@thinkpad:/home/paul#

This is with libreswan head, but I would not expect that to be different from a 3.4x version.

Is there a way for me to reproduce what you are seeing?
Comment 10 Miguel Angel Ajo 2021-04-13 07:57:26 UTC 
Interesting, I'll collect more info and try to setup a reproducer.
Comment 11 Miguel Angel Ajo 2021-04-13 07:58:33 UTC 
Thanks for looking so quickly Paul.
Comment 12 Miguel Angel Ajo 2021-04-13 11:58:57 UTC 
More info, this will hopefully help you reproduce it, I missed a command because apparently we don't print it out to the submariner debug info.


[root@cluster2-worker submariner]# cat /etc/fedora-release 
Fedora release 33 (Thirty Three)
[root@cluster2-worker submariner]# ipsec version
Linux Libreswan 4.3 (netkey) on 5.11.7-100.fc32.x86_64



Having docker (works with podman too):

$ docker run -ti --privileged --entrypoint /bin/bash quay.io/submariner/submariner-gateway:devel 

[root@c32883b89317 submariner]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
270: eth0@if271: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:11:00:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.4/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever


[root@8fd7f0476fc0 submariner]# pluto &
...


[root@8fd7f0476fc0 submariner]# /usr/libexec/ipsec/whack --psk --encrypt --name submariner-cable-kind2-172-18-0-9-0-0 --id 172.17.0.4 --host 172.17.0.4 --client 172.17.0.4/32 --ikeport 4511 --to --id 172.18.0.9 --host 172.18.0.9 --client 172.18.0.9/32 --ikeport 4502
pluto[332]: adding UDP interface eth0 172.17.0.4:4511
002 adding UDP interface eth0 172.17.0.4:4511
pluto[332]: "submariner-cable-kind2-172-18-0-9-0-0": added IKEv2 connection
002 "submariner-cable-kind2-172-18-0-9-0-0": added IKEv2 connection



[root@8fd7f0476fc0 submariner]# /usr/libexec/ipsec/whack --route --name submariner-cable-kind2-172-18-0-9-0-0
pluto[332]: "submariner-cable-kind2-172-18-0-9-0-0": cannot install route: peer is within its client
003 "submariner-cable-kind2-172-18-0-9-0-0": cannot install route: peer is within its client
025 "submariner-cable-kind2-172-18-0-9-0-0": could not route


Normally after that we would do: 
/usr/libexec/ipsec/whack --initiate --asynchronous --name submariner-cable-kind2-172-18-0-9-0-0
Comment 13 Miguel Angel Ajo 2021-04-13 12:01:27 UTC 
Wait, try only with docker, with podman something is missing in terms of permissions/mounts
[root@d919399106ab submariner]# WARNING: cannot change /proc/sys/net/core/xfrm_acq_expires from  to 30
FAILURE in loading XFRM IPsec stack

[1]+  Exit 1                  pluto
Comment 14 Miguel Angel Ajo 2021-04-13 12:18:21 UTC 
Another discovery on my side: this only reproduces if both left & right ikeports are != 4500
Comment 15 Paul Wouters 2021-04-13 13:13:29 UTC 
(In reply to Miguel Angel Ajo from comment #13)
> Wait, try only with docker, with podman something is missing in terms of
> permissions/mounts
> [root@d919399106ab submariner]# WARNING: cannot change
> /proc/sys/net/core/xfrm_acq_expires from  to 30
> FAILURE in loading XFRM IPsec stack
> 
> [1]+  Exit 1                  pluto

This warning comes from _stackmanager. That should probably not be called when you are inside a namespace. The warning is not fatal though. Something else likely happened that was fatal, like the host not having the XFRM modules loaded in the kernel, so these are not available in the container/namespace either.
Comment 16 Paul Wouters 2021-04-13 13:52:52 UTC 
upstream fix: https://github.com/libreswan/libreswan/commit/d0f1bdefd91f2040105092a2f1bc65b98e5d8052

test case confirming fix: https://github.com/libreswan/libreswan/tree/main/testing/pluto/ikev2-ikeport-06-host-to-host
Comment 17 Paul Wouters 2021-04-13 13:55:05 UTC 
Fix will be in upstream 4.4, so should come in via rebase. If a z-stream is needed, please file a separate rhbz for a backport fix. The fix is trivial and has an easy upstream test case.
Comment 18 Paul Wouters 2021-04-13 14:15:01 UTC 
Created attachment 1771628 [details]
backport patch for libreswan 4.3

backport patch for libreswan 4.3
Comment 23 Paul Wouters 2021-04-22 19:46:40 UTC 
addressed in libreswan 4.4, should come in via rebase.
Comment 25 Ondrej Moriš 2021-05-05 11:37:36 UTC 
I noticed Doc Text was missing, we wanted this to be documented as Known Issues in RHEL-8.4 if it is not too late for it already. Here's the first draft:

Cause: 

When ikeport options is specified in host-to-host libreswan connection, it is ignored.

Consequence: 

libreswan does not use specified port for IKE

Workaround (if any): 

None.

Result: 

IKE uses default ports 500/4500 regardless of ikeport setting.
Comment 39 errata-xmlrpc 2021-11-09 18:49:51 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 (libreswan bug fix and enhancement update), 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-2021:4299
Note You need to log in before you can comment on or make changes to this bug.