Bug 1934058
| Summary: | ikeport does not work for host-to-host | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Ondrej Moriš <omoris> | ||||
| Component: | libreswan | Assignee: | Daiki Ueno <dueno> | ||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||
| Severity: | low | Docs Contact: | Khushbu Borole <kborole> | ||||
| Priority: | low | ||||||
| Version: | 8.4 | CC: | kborole, majopela, mjahoda, sahana, smattar | ||||
| Target Milestone: | rc | Keywords: | Triaged | ||||
| Target Release: | 8.5 | Flags: | pm-rhel:
mirror+
|
||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| 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.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-11-09 18:49:51 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: | 1958968 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Acceptance Criteria: * [gating] connection can be established when using ikeport and chosen port is actually used for IKE Confirmed this issue. Created a new upstream test case ikev2-ikeport-06-host-to-host 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 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 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. 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.
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? 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?
Interesting, I'll collect more info and try to setup a reproducer. Thanks for looking so quickly Paul. 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
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 Another discovery on my side: this only reproduces if both left & right ikeports are != 4500 (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. 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 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. Created attachment 1771628 [details]
backport patch for libreswan 4.3
backport patch for libreswan 4.3
addressed in libreswan 4.4, should come in via rebase. 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. 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 |
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.