Project

General

Profile

Issue #2722

Traffic begins to pass directly bypassing IPsec policies

Added by Alexander Sukhomlinov about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Affected version:
5.6.3
Resolution:
No change required

Description

Hello.

So, basic schema host-to-host or host-to-site, but roadwarriors in the same network, example 192.168.1.0/24:

Host-to-site:
_______

Gateway:


conn gateway
        keyexchange=ikev2
        ike=aes256gcm8-sha2_512-modp4096!
        esp=aes256gcm8-modp4096!
        left=%192.168.1.1
        leftcert=cert1
        leftid="<some_id>" 
        leftsubnet=192.168.20.0/24
        leftfirewall=yes
        right=%192.168.1.15
        rightid="<some_remote_id>" 
        rightfirewall=yes
        auto=route

Host1:


conn host1
        keyexchange=ikev2
        ike=aes256gcm8-sha2_512-modp4096!
        esp=aes256gcm8-modp4096!
        left=%192.168.1.15
        leftcert=cert2
        leftid="<some_id>" 
        leftfirewall=yes
        right=%192.168.1.1
        rightsubnet=192.168.20.0/24
        rightid="<some_remote_id>" 
        rightfirewall=yes
        auto=route

OR just:

Host-to-host:
_______

Host1:


conn host1
        keyexchange=ikev2
        ike=aes256gcm8-sha2_512-modp4096!
        esp=aes256gcm8-modp4096!
        left=%192.168.1.1
        leftcert=cert1
        leftid="<some_id>" 
        leftfirewall=yes
        right=%192.168.1.2
        rightid="<some_remote_id>" 
        rightfirewall=yes
        auto=route

Host2:


conn host2
        keyexchange=ikev2
        ike=aes256gcm8-sha2_512-modp4096!
        esp=aes256gcm8-modp4096!
        left=%192.168.1.2
        leftcert=cert2
        leftid="<some_id>" 
        leftfirewall=yes
        right=%192.168.1.1
        rightid="<some_remote_id>" 
        rightfirewall=yes
        auto=route

So, basically Strongswan installs kernel traps and initiate connection as it should, but:

1. If you did a mistake on purpose (in example host-to-host) in configs and make strongswan one of sides AUTH_FAILED, traffic still going in. But it should stop, because of AUTH_FAIED. ip xfrm policy install policies, but traffic still flow and ignore it...
2. Traffic (icmp-requests as example in host-to-site) may go through tunnel, and be encrypted (ipsec statusall or ip xfrm monitor indicate it), but icmp-reply may go out from tunnel unencrypted.

Ping from 192.168.1.15 to 192.168.20.14 (encrypted) -> gateway (decrypt it, and route to 20.0/24 subnet, 20.1 as ip gateway for such subnet) -> 20.14 making reply to 1.15 -> gateway 20.1 (here traffic do not go over ipsec policies\xfrm and go to 1.15 as is! ipsec statusall or ip xfrm monitor don't show it! bytes_o - equals zero) -> go directly to 1.15...

It happens after 5.6.3. Also it happens ONLY when both gateways\hosts where left\right in same network. In 5.6.2 - everything works fine!

History

#1 Updated by Tobias Brunner about 3 years ago

  • Tracker changed from Bug to Issue
  • Status changed from New to Feedback
  • Start date deleted (09.08.2018)

What are you talking about? What SA would there be to tunnel packets into if the authentication failed? And what's that about "ip xfrm policy install"? Are you installing policies manually? Provide more information if you think there is a problem (actual output of the commands you refer to, traffic dumps, logs etc.).

#2 Updated by Alexander Sukhomlinov about 3 years ago

Tobias Brunner wrote:

What are you talking about? What SA would there be to tunnel packets into if the authentication failed? And what's that about "ip xfrm policy install"? Are you installing policies manually? Provide more information if you think there is a problem (actual output of the commands you refer to, traffic dumps, logs etc.).

Im' sorry =( I wrote this in a hurry...

Host-to-host:
_

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
        strictcrlpolicy=no
        uniqueids = yes

#Main settings

conn %default
    dpdaction=clear
    dpddelay=5s
    dpdtimeout=15s

conn host1
        keyexchange=ikev2
        ike=aes256gcm8-sha2_512-modp4096!
        esp=aes256gcm8-modp4096!
        left=%192.168.1.1
        leftcert=cert1
        leftid="C=CH, O=strongSwan, CN=host1" 
        leftfirewall=yes
        right=%192.168.1.2
        rightid="C=CH, O=strongSwan, CN=host2" 
        rightfirewall=yes
        auto=route

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
        strictcrlpolicy=no
        uniqueids = yes

#Main settings

conn %default
    dpdaction=clear
    dpddelay=5s
    dpdtimeout=15s

conn host2
        keyexchange=ikev2
        ike=aes256gcm8-sha2_512-modp4096!
        esp=aes256gcm8-modp4096!
        left=%192.168.1.2
        leftcert=cert2
        leftid="C=CH, O=strongSwan, CN=host2" 
        leftfirewall=yes
        right=%192.168.1.1
        rightid="C=CH, O=strongSwan, CN=host1" 
        rightfirewall=yes
        auto=route

Now test it:

host1 output:

# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.326 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.281 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.340 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.290 ms
# ipsec statusall

Status of IKE charon daemon (strongSwan 5.6.3, Linux 4.4.16, x86_64):
  uptime: 3 minutes, since Aug 10 09:23:59 2018  
  malloc: sbrk 2686976, mmap 0, used 542784, free 2144192
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 xcbc cmac hmac ctr ccm gcm
 curl attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown xauth-generic dhcp unity counters
Listening IP addresses:
  192.168.7.246
  192.168.30.1
  192.168.1.1
  169.0.0.1
Connections:
       host1:  192.168.1.1,0.0.0.0/0,::/0...192.168.1.2,0.0.0.0/0,::/0  IKEv2, dpddelay=5s
       host1:   local:  [C=CH, O=strongSwan, CN=host1] uses public key authentication
       host1:    cert:  "C=CH, O=strongSwan, CN=host1" 
       host1:   remote: [C=CH, O=strongSwan, CN=host2] uses public key authentication
       host1:   child:  192.168.1.1/32 === 192.168.1.2/32 TUNNEL, dpdaction=clear
Routed Connections:
       host1{1}:  ROUTED, TUNNEL, reqid 1
       host1{1}:   192.168.1.1/32 === 192.168.1.2/32
Security Associations (0 up, 0 connecting):
  none

# ip xfrm monitor
<empty>
# tcpdump -i enp3s0 -nn -vv

09:25:36.650862 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.2, length 46
09:25:36.650905 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.1 is-at 00:60:e0:68:da:90, length 28
09:26:42.049711 IP (tos 0x0, ttl 64, id 9425, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.1 > 192.168.1.2: ICMP echo request, id 12911, seq 1, length 64
09:26:42.049959 IP (tos 0x0, ttl 64, id 55387, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.1.2 > 192.168.1.1: ICMP echo reply, id 12911, seq 1, length 64
09:26:43.049464 IP (tos 0x0, ttl 64, id 10238, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.1 > 192.168.1.2: ICMP echo request, id 12911, seq 2, length 64
09:26:43.049682 IP (tos 0x0, ttl 64, id 55794, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.1.2 > 192.168.1.1: ICMP echo reply, id 12911, seq 2, length 64
09:26:44.049502 IP (tos 0x0, ttl 64, id 10249, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.1 > 192.168.1.2: ICMP echo request, id 12911, seq 3, length 64
09:26:44.049756 IP (tos 0x0, ttl 64, id 56044, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.1.2 > 192.168.1.1: ICMP echo reply, id 12911, seq 3, length 64
09:26:45.049485 IP (tos 0x0, ttl 64, id 11217, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.1 > 192.168.1.2: ICMP echo request, id 12911, seq 4, length 64
09:26:45.049717 IP (tos 0x0, ttl 64, id 56727, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.1.2 > 192.168.1.1: ICMP echo reply, id 12911, seq 4, length 64

....

Aug 10 09:23:59 7246 daemon: 00[LIB] loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown xauth-generic dhcp unity counters
Aug 10 09:23:59 7246 daemon: 00[LIB] unable to load 14 plugin features (13 due to unmet dependencies)
Aug 10 09:23:59 7246 daemon: 00[JOB] spawning 16 worker threads
Aug 10 09:23:59 7246 daemon: 02[LIB] created thread 02 [9084]
Aug 10 09:23:59 7246 daemon: 01[LIB] created thread 01 [9083]
Aug 10 09:23:59 7246 daemon: 05[LIB] created thread 05 [9087]
Aug 10 09:23:59 7246 daemon: 04[LIB] created thread 04 [9086]
Aug 10 09:23:59 7246 daemon: 03[LIB] created thread 03 [9085]
Aug 10 09:23:59 7246 daemon: 06[LIB] created thread 06 [9088]
Aug 10 09:23:59 7246 daemon: 07[LIB] created thread 07 [9089]
Aug 10 09:23:59 7246 daemon: 08[LIB] created thread 08 [9090]
Aug 10 09:23:59 7246 daemon: 09[LIB] created thread 09 [9091]
Aug 10 09:23:59 7246 daemon: 10[LIB] created thread 10 [9092]
Aug 10 09:23:59 7246 daemon: 11[LIB] created thread 11 [9093]
Aug 10 09:23:59 7246 daemon: 12[LIB] created thread 12 [9094]
Aug 10 09:23:59 7246 daemon: 13[LIB] created thread 13 [9095]
Aug 10 09:23:59 7246 daemon: 15[LIB] created thread 15 [9096]
Aug 10 09:23:59 7246 daemon: 07[CFG] received stroke: add connection 'host1'
Aug 10 09:23:59 7246 daemon: 14[LIB] created thread 14 [9097]
Aug 10 09:23:59 7246 daemon: 16[LIB] created thread 16 [9098]
Aug 10 09:23:59 7246 daemon: 07[CFG]   loaded certificate "C=CH, O=strongSwan, CN=host1" from 'cert1'
Aug 10 09:23:59 7246 daemon: 07[CFG] added configuration 'host1'
Aug 10 09:23:59 7246 daemon: 06[CFG] received stroke: route 'host1'

# ip xfrm policy
src 192.168.1.1/32 dst 192.168.1.2/32 
        dir out priority 367232 ptype main 
        tmpl src 192.168.1.1 dst 192.168.1.2
                proto esp reqid 1 mode tunnel
src 192.168.1.2/32 dst 192.168.1.1/32 
        dir fwd priority 367232 ptype main 
        tmpl src 192.168.1.2 dst 192.168.1.1
                proto esp reqid 1 mode tunnel
src 192.168.1.2/32 dst 192.168.1.1/32 
        dir in priority 367232 ptype main 
        tmpl src 192.168.1.2 dst 192.168.1.1
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 ptype main 
src ::/0 dst ::/0 
        socket in priority 0 ptype main 
src ::/0 dst ::/0 
        socket out priority 0 ptype main 
src ::/0 dst ::/0 
        socket in priority 0 ptype main 
src ::/0 dst ::/0 
        socket out priority 0 ptype main

host2 output:

# ipsec statusall

Status of IKE charon daemon (strongSwan 5.6.3, Linux 4.4.16, x86_64):
  uptime: 6 minutes, since Aug 10 09:27:02 2018
  malloc: sbrk 2686976, mmap 0, used 542816, free 2144160
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 xcbc cmac hmac ctr ccm gcm
 curl attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown xauth-generic dhcp unity counters
Listening IP addresses:
  192.168.7.247
  192.168.31.1
  192.168.1.2
  169.0.0.1
Connections:
       host2:  192.168.1.2,0.0.0.0/0,::/0...192.168.1.1,0.0.0.0/0,::/0  IKEv2, dpddelay=5s
       host2:   local:  [C=CH, O=strongSwan, CN=host2] uses public key authentication
       host2:    cert:  "C=CH, O=strongSwan, CN=host2" 
       host2:   remote: [C=CH, O=strongSwan, CN=host1] uses public key authentication
       host2:   child:  192.168.1.2/32 === 192.168.1.1/32 TUNNEL, dpdaction=clear
Routed Connections:
       host2{1}:  ROUTED, TUNNEL, reqid 1
       host2{1}:   192.168.1.2/32 === 192.168.1.1/32
Security Associations (0 up, 0 connecting):
  none

# ip xfrm monitor
<empty>

# tcpdump -i enp3s0 -nn -vv

09:24:26.951926 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.2, length 28
09:24:26.952099 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.1 is-at 00:60:e0:68:da:90, length 46
09:25:32.351064 IP (tos 0x0, ttl 64, id 9425, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.1 > 192.168.1.2: ICMP echo request, id 12911, seq 1, length 64
09:25:32.351159 IP (tos 0x0, ttl 64, id 55387, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.1.2 > 192.168.1.1: ICMP echo reply, id 12911, seq 1, length 64
09:25:33.350803 IP (tos 0x0, ttl 64, id 10238, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.1 > 192.168.1.2: ICMP echo request, id 12911, seq 2, length 64
09:25:33.350873 IP (tos 0x0, ttl 64, id 55794, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.1.2 > 192.168.1.1: ICMP echo reply, id 12911, seq 2, length 64
09:25:34.350854 IP (tos 0x0, ttl 64, id 10249, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.1 > 192.168.1.2: ICMP echo request, id 12911, seq 3, length 64
09:25:34.350957 IP (tos 0x0, ttl 64, id 56044, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.1.2 > 192.168.1.1: ICMP echo reply, id 12911, seq 3, length 64
09:25:35.350819 IP (tos 0x0, ttl 64, id 11217, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.1 > 192.168.1.2: ICMP echo request, id 12911, seq 4, length 64
09:25:35.350914 IP (tos 0x0, ttl 64, id 56727, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.1.2 > 192.168.1.1: ICMP echo reply, id 12911, seq 4, length 64


....

Aug 10 09:27:02 7247 daemon: 00[LIB] loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown xauth-generic dhcp unity counters
Aug 10 09:27:02 7247 daemon: 00[LIB] unable to load 14 plugin features (13 due to unmet dependencies)
Aug 10 09:27:02 7247 daemon: 00[JOB] spawning 16 worker threads
Aug 10 09:27:02 7247 daemon: 01[LIB] created thread 01 [31364]
Aug 10 09:27:02 7247 daemon: 06[LIB] created thread 06 [31363]
Aug 10 09:27:02 7247 daemon: 03[LIB] created thread 03 [31366]
Aug 10 09:27:02 7247 daemon: 04[LIB] created thread 04 [31367]
Aug 10 09:27:02 7247 daemon: 02[LIB] created thread 02 [31365]
Aug 10 09:27:02 7247 daemon: 07[LIB] created thread 07 [31370]
Aug 10 09:27:02 7247 daemon: 09[LIB] created thread 09 [31371]
Aug 10 09:27:02 7247 daemon: 08[LIB] created thread 08 [31369]
Aug 10 09:27:02 7247 daemon: 05[LIB] created thread 05 [31368]
Aug 10 09:27:02 7247 daemon: 10[LIB] created thread 10 [31372]
Aug 10 09:27:02 7247 daemon: 11[LIB] created thread 11 [31373]
Aug 10 09:27:02 7247 daemon: 16[LIB] created thread 16 [31379]
Aug 10 09:27:02 7247 daemon: 12[LIB] created thread 12 [31374]
Aug 10 09:27:02 7247 daemon: 02[CFG] received stroke: add connection 'host2'
Aug 10 09:27:02 7247 daemon: 13[LIB] created thread 13 [31375]
Aug 10 09:27:02 7247 daemon: 14[LIB] created thread 14 [31376]
Aug 10 09:27:02 7247 daemon: 15[LIB] created thread 15 [31377]
Aug 10 09:27:02 7247 daemon: 02[CFG]   loaded certificate "C=CH, O=strongSwan, CN=host2" from 'cert2'
Aug 10 09:27:02 7247 daemon: 02[CFG] added configuration 'host2'
Aug 10 09:27:02 7247 daemon: 09[CFG] received stroke: route 'host2'

# ip xfrm pol
src 192.168.1.2/32 dst 192.168.1.1/32 
        dir out priority 367232 ptype main 
        tmpl src 192.168.1.2 dst 192.168.1.1
                proto esp reqid 1 mode tunnel
src 192.168.1.1/32 dst 192.168.1.2/32 
        dir fwd priority 367232 ptype main 
        tmpl src 192.168.1.1 dst 192.168.1.2
                proto esp reqid 1 mode tunnel
src 192.168.1.1/32 dst 192.168.1.2/32 
        dir in priority 367232 ptype main 
        tmpl src 192.168.1.1 dst 192.168.1.2
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 ptype main 
src ::/0 dst ::/0 
        socket in priority 0 ptype main 
src ::/0 dst ::/0 
        socket out priority 0 ptype main 
src ::/0 dst ::/0 
        socket in priority 0 ptype main 
src ::/0 dst ::/0 
        socket out priority 0 ptype main 

As we see here, all policies installed correctly, but traffic flows directly from 192.168.1.1 to 1.2 ingoring them, also there is no connection initiation at all...

I do not install policies manually!

Sometimes it can initiate connection, and traffic will flow over tunnel, sometimes not, cannot reproduce it =(


Another example is to up the connection (auto=start or ipsec up host1) and simulate AUTHENTICATION_FAILED, making a deliberate mistake in the config by changing in one of the peer:

host2:

rightid="C=CH, O=strongSwan, CN=blabla-this is-wrong-id" 

host1:

# ipsec up host1
no files found matching '/srv/etc/strongswan.d/*.conf'
initiating IKE_SA host1[1] to 192.168.1.2
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 192.168.1.1[500] to 192.168.1.2[500] (712 bytes)
received packet: from 192.168.1.2[500] to 192.168.1.1[500] (737 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
received cert request for "C=CH, O=strongSwan, CN=strongSwan CA" 
sending cert request for "C=CH, O=strongSwan, CN=strongSwan CA" 
authentication of 'C=CH, O=strongSwan, CN=host1' (myself) with RSA_EMSA_PKCS1_SHA2_256 successful
sending end entity cert "C=CH, O=strongSwan, CN=host1" 
establishing CHILD_SA host1{2}
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
splitting IKE message with length of 1428 bytes into 2 fragments
generating IKE_AUTH request 1 [ EF(1/2) ]
generating IKE_AUTH request 1 [ EF(2/2) ]
sending packet: from 192.168.1.1[4500] to 192.168.1.2[4500] (1248 bytes)
sending packet: from 192.168.1.1[4500] to 192.168.1.2[4500] (237 bytes)
received packet: from 192.168.1.2[4500] to 192.168.1.1[4500] (57 bytes)
parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error
establishing connection 'host1' failed

Traffic still flow


# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.334 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.270 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.290 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.392 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=0.320 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=0.279 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=64 time=0.301 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=0.260 ms

It happened after 5.6.3. In 5.6.2 - If both sides somehow cannot authenticate or other errors,etc... Traffic will stuck and will not go directly!

Systems did not update 2 years, except strongswan and openssl.

Like this: - "Ok man, i see your traffic match ipsec policies, so go through them .... Hey man, we cannot authenticate each other, or we get other errors, you shall not pass!"

P.S. - Maybe i'm blind. But don't know what's happened...

#3 Updated by Alexander Sukhomlinov about 3 years ago

Also forgot to say:

If we manually up connection:

Status of IKE charon daemon (strongSwan 5.5.0, Linux 4.4.16, x86_64):
  uptime: 24 minutes, since Aug 10 12:23:15 2018
  malloc: sbrk 2703360, mmap 0, used 545040, free 2158320
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac ctr ccm gcm curl attr kerne
l-netlink resolve socket-default connmark forecast farp stroke vici updown xauth-generic dhcp unity
Listening IP addresses:
  192.168.7.246
  192.168.30.1
  192.168.1.1
  169.0.0.1
Connections:
       host1:  192.168.1.1...192.168.1.2  IKEv2, dpddelay=5s
       host1:   local:  [C=CH, O=strongSwan, CN=host1] uses public key authentication
       host1:    cert:  "C=CH, O=strongSwan, CN=host1" 
       host1:   remote: [C=CH, O=strongSwan, CN=host2] uses public key authentication
       host1:   child:  192.168.1.1/32 === 192.168.1.2/32 TUNNEL, dpdaction=clear
Routed Connections:
       host1{1}:  ROUTED, TUNNEL, reqid 1
       host1{1}:   192.168.1.1/32 === 192.168.1.2/32
Security Associations (1 up, 0 connecting):
       host1[1]: ESTABLISHED 3 minutes ago, 192.168.1.1[C=CH, O=strongSwan, CN=host1]...192.168.1.2[C=CH, O=strongSwan, CN=host2]  
       host1[1]: IKEv2 SPIs: ba4e914b6e88e2bb_i* a5fd67c17c3b967d_r, public key reauthentication in 2 hours
       host1[1]: IKE proposal: AES_GCM_8_256/PRF_HMAC_SHA2_512/MODP_4096
       host1{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cd004982_i cce7a32e_o
       host1{2}:  AES_GCM_8_256, 0 bytes_i, 0 bytes_o, rekeying in 45 minutes
       host1{2}:   192.168.1.1/32 === 192.168.1.2/32

We see established\installed SA here. But traffic still ignore it and go directly (0 bytes_i, 0 bytes_o), also nothing in "ip xfrm monitor"

#4 Updated by Tobias Brunner about 3 years ago

I think the installed policies look fine. So if the kernel does not match them that's a kernel problem, not something strongSwan can really influence. Therefore, I don't know how the strongSwan version could make a difference here (if that's really the case, maybe try comparing the output of the different commands between the versions).

#5 Updated by Alexander Sukhomlinov about 3 years ago

Thx for reply. Ok will try to, and will provide info a bit later...

#6 Updated by Alexander Sukhomlinov about 3 years ago

Don't know what happened. Yes, there is something in kernel. I just rebuild it - "make distclean and make all"

Now, everything is fine! Im' sorry for this and wasting your time Tobias, issue should be closed or maybe deleted =)

#7 Updated by Tobias Brunner about 3 years ago

  • Category changed from kernel-interface to kernel
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

Also available in: Atom PDF