Score:2

ipsec duplicate policies: allow and block

in flag

I'm trying to set up u IPsec connection between two virtual machines using Strongswan. The configuration on my first machine is the following (ipsec.conf):

conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    mobike=no
    keyexchange=ikev2
    authby=pubkey
    esp=null-sha1!
conn host-to-host
    left=192.168.56.102
    leftcert=/etc/ipsec.d/certs/servercert.pem
    leftid="C=..., ST=..., O=..., OU=SSTT, CN=www.sstt.org"
    right=192.168.56.101
    rightid="C=..., ST=..., O=..., OU=SSTT, CN=name"
    type=tunnel
    auto=start

The file ipsec.secrets contains the correct route to the private key. The configuration on my second machine matches one listed here.

My problem is: when the SA gets established for some reason on my first machine (server) the policy list looks like this:

src 192.168.56.101/32 dst 192.168.56.102/32 
    dir fwd priority 2819 
    tmpl src 192.168.56.101 dst 192.168.56.102
        proto esp reqid 1 mode tunnel
src 192.168.56.101/32 dst 192.168.56.102/32 
    dir in priority 2819 
    tmpl src 192.168.56.101 dst 192.168.56.102
        proto esp reqid 1 mode tunnel
src 192.168.56.102/32 dst 192.168.56.101/32 
    dir out priority 2819 
    tmpl src 192.168.56.102 dst 192.168.56.101
        proto esp reqid 1 mode tunnel
src 192.168.56.101/32 dst 192.168.56.102/32 
    dir fwd action block priority 12035 
src 192.168.56.101/32 dst 192.168.56.102/32 
    dir in action block priority 12035 
src 192.168.56.102/32 dst 192.168.56.101/32 
    dir out action block priority 12035

The client machine's policy list is does not have any policies with blocking action, only the correct policies.

I captured some traffic with wireshark and found that when my server pings the second machine the ICMP packets get sent twice, once with the ESP header and once without. The second machine only replies to the ones without.

I've tried just deleting the policies with block action but it obviously didn't work.

Log output after restarting the service on server side:

Jun 11 15:29:28 ubuntu-server charon: 00[DMN] signal of type SIGINT received. Shutting down
Jun 11 15:29:28 ubuntu-server charon: 00[IKE] deleting IKE_SA host-to-host[2] between 192.168.56.102[C=..., ST=..., O=..., OU=SSTT, CN=www.sstt.org]...192.168.56.101[C=..., ST=..., O=..., OU=SSTT, CN=name]
Jun 11 15:29:28 ubuntu-server charon: 00[IKE] sending DELETE for IKE_SA host-to-host[2]
Jun 11 15:29:28 ubuntu-server charon: 00[ENC] generating INFORMATIONAL request 0 [ D ]
Jun 11 15:29:28 ubuntu-server charon: 00[NET] sending packet: from 192.168.56.102[500] to 192.168.56.101[500] (76 bytes)
Jun 11 15:29:30 ubuntu-server charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-186-generic, x86_64)
Jun 11 15:29:30 ubuntu-server charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Jun 11 15:29:30 ubuntu-server charon: 00[CFG]   loaded ca certificate "C=..., ST=..., O=..., OU=SSTT, CN=ca.sstt.org" from '/etc/ipsec.d/cacerts/cacert.pem'
Jun 11 15:29:30 ubuntu-server charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Jun 11 15:29:30 ubuntu-server charon: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Jun 11 15:29:30 ubuntu-server charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Jun 11 15:29:30 ubuntu-server charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Jun 11 15:29:30 ubuntu-server charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Jun 11 15:29:30 ubuntu-server charon: 00[CFG]   loaded RSA private key from '/etc/ipsec.d/private/serverkey.pem'
Jun 11 15:29:30 ubuntu-server charon: 00[LIB] loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown
Jun 11 15:29:30 ubuntu-server charon: 00[LIB] dropped capabilities, running as uid 0, gid 0
Jun 11 15:29:30 ubuntu-server charon: 00[JOB] spawning 16 worker threads
Jun 11 15:29:30 ubuntu-server charon: 11[CFG] received stroke: add connection 'host-to-host'
Jun 11 15:29:30 ubuntu-server charon: 11[CFG]   loaded certificate "C=..., ST=..., O=..., OU=SSTT, CN=www.sstt.org" from '/etc/ipsec.d/certs/servercert.pem'
Jun 11 15:29:30 ubuntu-server charon: 11[CFG] added configuration 'host-to-host'
Jun 11 15:29:30 ubuntu-server charon: 13[CFG] received stroke: initiate 'host-to-host'
Jun 11 15:29:30 ubuntu-server charon: 13[IKE] initiating IKE_SA host-to-host[1] to 192.168.56.101
Jun 11 15:29:30 ubuntu-server charon: 13[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
Jun 11 15:29:30 ubuntu-server charon: 13[NET] sending packet: from 192.168.56.102[500] to 192.168.56.101[500] (1124 bytes)
Jun 11 15:29:30 ubuntu-server charon: 15[NET] received packet: from 192.168.56.101[500] to 192.168.56.102[500] (481 bytes)
Jun 11 15:29:30 ubuntu-server charon: 15[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(HASH_ALG) N(MULT_AUTH) ]
Jun 11 15:29:30 ubuntu-server charon: 15[IKE] received cert request for "C=..., ST=..., O=..., OU=SSTT, CN=ca.sstt.org"
Jun 11 15:29:30 ubuntu-server charon: 15[IKE] sending cert request for "C=..., ST=..., O=..., OU=SSTT, CN=ca.sstt.org"
Jun 11 15:29:30 ubuntu-server charon: 15[IKE] authentication of 'C=..., ST=..., O=..., OU=SSTT, CN=www.sstt.org' (myself) with RSA_EMSA_PKCS1_SHA256 successful
Jun 11 15:29:30 ubuntu-server charon: 15[IKE] sending end entity cert "C=..., ST=..., O=..., OU=SSTT, CN=www.sstt.org"
Jun 11 15:29:30 ubuntu-server charon: 15[IKE] establishing CHILD_SA host-to-host
Jun 11 15:29:30 ubuntu-server charon: 15[ENC] generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
Jun 11 15:29:30 ubuntu-server charon: 15[NET] sending packet: from 192.168.56.102[500] to 192.168.56.101[500] (1628 bytes)
Jun 11 15:29:30 ubuntu-server charon: 16[NET] received packet: from 192.168.56.101[500] to 192.168.56.102[500] (1500 bytes)
Jun 11 15:29:30 ubuntu-server charon: 16[ENC] parsed IKE_AUTH response 1 [ IDr CERT AUTH SA TSi TSr N(AUTH_LFT) ]
Jun 11 15:29:30 ubuntu-server charon: 16[IKE] received end entity cert "C=..., ST=..., O=..., OU=SSTT, CN=name"
Jun 11 15:29:30 ubuntu-server charon: 16[CFG]   using certificate "C=..., ST=..., O=..., OU=SSTT, CN=name"
Jun 11 15:29:30 ubuntu-server charon: 16[CFG]   using trusted ca certificate "C=..., ST=..., O=..., OU=SSTT, CN=ca.sstt.org"
Jun 11 15:29:30 ubuntu-server charon: 16[CFG] checking certificate status of "C=..., ST=..., O=..., OU=SSTT, CN=name"
Jun 11 15:29:30 ubuntu-server charon: 16[CFG] certificate status is not available
Jun 11 15:29:30 ubuntu-server charon: 16[CFG]   reached self-signed root ca with a path length of 0
Jun 11 15:29:30 ubuntu-server charon: 16[IKE] authentication of 'C=..., ST=..., O=..., OU=SSTT, CN=name' with RSA_EMSA_PKCS1_SHA256 successful
Jun 11 15:29:30 ubuntu-server charon: 16[IKE] IKE_SA host-to-host[1] established between 192.168.56.102[C=..., ST=..., O=..., OU=SSTT, CN=www.sstt.org]...192.168.56.101[C=..., ST=..., O=..., OU=SSTT, CN=name]
Jun 11 15:29:30 ubuntu-server charon: 16[IKE] scheduling reauthentication in 3250s
Jun 11 15:29:30 ubuntu-server charon: 16[IKE] maximum IKE_SA lifetime 3430s
Jun 11 15:29:30 ubuntu-server charon: 16[KNL] policy already exists, try to update it
Jun 11 15:29:30 ubuntu-server charon: message repeated 2 times: [ 16[KNL] policy already exists, try to update it]
Jun 11 15:29:30 ubuntu-server charon: 16[IKE] CHILD_SA host-to-host{1} established with SPIs c056e14a_i c62093a4_o and TS 192.168.56.102/32 === 192.168.56.101/32
Jun 11 15:29:30 ubuntu-server charon: 16[IKE] received AUTH_LIFETIME of 3364s, scheduling reauthentication in 3184s

Can someone explain what's going on? thanks in advance

cn flag
I don't know where the block policies come from, but they are not relevant because their priority is lower (higher number). Try increasing the log level for _knl_ to 2 or 3 to see if and when they are installed by strongSwan (but they might not because there is actually a log message about existing policies). Also, if you captured traffic on the receiving side, it's completely normal to see the inbound packets twice (see [this FAQ entry](https://wiki.strongswan.org/projects/strongswan/wiki/FAQ#Capturing-outbound-plaintext-packets-with-tcpdumpwireshark)).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.