strongSwan

sorry version packaged with pfsense 2.4.2 is strongswan 5.6.0

Status of IKE charon daemon (strongSwan 5.6.0, FreeBSD 11.1-RELEASE-p4, amd64):
  uptime: 5 hours, since Dec 01 09:35:14 2017
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 10
  loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf curve25519 xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock
Listening IP addresses:
  172.16.199.1
  A.B.C.D
 [other ips]
Connections:
   bypasslan:  %any...%any  IKEv1/2
   bypasslan:   local:  uses public key authentication
   bypasslan:   remote: uses public key authentication
   bypasslan:   child:  172.16.199.0/24|/0 === 172.16.199.0/24|/0 PASS
     con1000:  A.B.C.D...X.Y.Z.W  IKEv2
     con1000:   local:  [A.B.C.D] uses pre-shared key authentication
     con1000:   remote: [X.Y.Z.W] uses pre-shared key authentication
     con1000:   child:  172.16.199.0/24|/0 === 10.128.0.0/16|/0 TUNNEL
     con1001:   child:  172.16.199.0/24|/0 === 10.128.200.0/24|/0 TUNNEL
     con1002:   child:  172.16.199.0/24|/0 === 192.168.3.0/24|/0 TUNNEL
     con1003:   child:  172.16.199.0/24|/0 === 10.15.1.0/24|/0 TUNNEL
     con1004:   child:  172.16.199.0/24|/0 === 10.128.210.0/24|/0 TUNNEL
     con1005:   child:  172.16.199.0/24|/0 === 10.128.30.0/24|/0 TUNNEL
Shunted Connections:
   bypasslan:  172.16.199.0/24|/0 === 172.16.199.0/24|/0 PASS
Routed Connections:
     con1005{6}:  ROUTED, TUNNEL, reqid 6
     con1005{6}:   172.16.199.0/24|/0 === 10.128.30.0/24|/0
     con1004{5}:  ROUTED, TUNNEL, reqid 5
     con1004{5}:   172.16.199.0/24|/0 === 10.128.210.0/24|/0
     con1003{4}:  ROUTED, TUNNEL, reqid 4
     con1003{4}:   172.16.199.0/24|/0 === 10.15.1.0/24|/0
     con1002{3}:  ROUTED, TUNNEL, reqid 3
     con1002{3}:   172.16.199.0/24|/0 === 192.168.3.0/24|/0
     con1001{2}:  ROUTED, TUNNEL, reqid 2
     con1001{2}:   172.16.199.0/24|/0 === 10.128.200.0/24|/0
     con1000{1}:  ROUTED, TUNNEL, reqid 1
     con1000{1}:   172.16.199.0/24|/0 === 10.128.0.0/16|/0
Security Associations (1 up, 0 connecting):
     con1000[6]: ESTABLISHED 68 minutes ago, A.B.C.D[A.B.C.D]...X.Y.Z.W[X.Y.Z.W]
     con1000[6]: IKEv2 SPIs: c0ef27e9494feba4_i* bf78f6caba513a2e_r, pre-shared key reauthentication in 22 hours
     con1000[6]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
     con1002{60}:  INSTALLED, TUNNEL, reqid 3, ESP SPIs: cdd2d1c9_i b2a07979_o
     con1002{60}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 35776 bytes_o (28 pkts, 26s ago), rekeying in 17 minutes
     con1002{60}:   172.16.199.0/24|/0 === 192.168.3.0/24|/0
     con1002{61}:  INSTALLED, TUNNEL, reqid 3, ESP SPIs: cc3d37cd_i 5642404a_o
     con1002{61}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 468024 bytes_o (376 pkts, 26s ago), rekeying in 20 minutes
     con1002{61}:   172.16.199.0/24|/0 === 192.168.3.0/24|/0
     con1003{62}:  INSTALLED, TUNNEL, reqid 4, ESP SPIs: c8f9502c_i 43524eca_o
     con1003{62}:  3DES_CBC/HMAC_SHA1_96, 33915 bytes_i (135 pkts, 226s ago), 36168 bytes_o (128 pkts, 226s ago), rekeying in 19 minutes
     con1003{62}:   172.16.199.0/24|/0 === 10.15.1.0/24|/0
     con1001{63}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: c766d8fe_i 428c0edf_o
     con1001{63}:  3DES_CBC/HMAC_SHA1_96, 276497 bytes_i (906 pkts, 8s ago), 164728 bytes_o (1186 pkts, 8s ago), rekeying in 26 minutes
     con1001{63}:   172.16.199.0/24|/0 === 10.128.200.0/24|/0
     con1000{64}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c6078929_i 1c467c85_o
     con1000{64}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 30 minutes
     con1000{64}:   172.16.199.0/24|/0 === 10.128.0.0/16|/0

The traffic selectors for con1000 and con1001, con1004 and con1005 overlap (10.128.0.0/16 contains 10.128.200.0/24, 10.128.210.0/24 and 10.128.30.0/24) what was your intention behind this?

I have many questions but I suppose that the root cause is me not understanding precisely what
are the selectors.

Then please learn about it and ask specific questions. Start with HelpRequests and the linked pages (e.g. IntroductionToStrongswan and UsableExamples).

the /16 overlaps because without it I have this beavhiour (not in the attached logs but it is the original problem stated here https://lists.strongswan.org/pipermail/users/2017-November/011870.html)

but basically

Nov 29 10:57:33 iulm03 charon: 15[NET] <con1000|37> received packet: from X.Y.Z.W[500] to A.B.C.D[500] (236 bytes)
Nov 29 10:57:33 iulm03 charon: 15[ENC] <con1000|37> parsed CREATE_CHILD_SA request 0 [ SA No TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
Nov 29 10:57:33 iulm03 charon: 15[IKE] <con1000|37> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> looking for a child config for 172.16.199.98/32|/0[tcp/http] 172.16.199.0/24|/0 === 10.128.132.198/32|/0[tcp/49179] 10.128.0.0/16|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for us:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>  172.16.199.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for other:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>  10.128.200.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>   candidate "con1000" with prio 7+1
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for us:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>  172.16.199.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for other:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>  192.168.3.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for us:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>  172.16.199.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for other:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>  10.15.1.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for us:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>  172.16.199.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for other:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>  10.128.210.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>   candidate "con1003" with prio 7+1
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for us:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>  172.16.199.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for other:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>  10.128.30.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>   candidate "con1004" with prio 7+1
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> found matching child config "con1000" with prio 8
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> selecting proposal:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37>   proposal matches

adding the 128.200.0.0/16 prevents this happening

I think I have a basic understanding of traffic selector but I do not understand why

10.128.132.198/32|/0[tcp/49179] 10.128.0.0/16|/

gets these matches

Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> 10.128.200.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> candidate "con1000" with prio 7+1
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> proposing traffic selectors for other:
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> 10.128.30.0/24|/0
Nov 29 10:57:33 iulm03 charon: 15[CFG] <con1000|37> candidate "con1004" with prio 7+1

it's the whole situation that is not clear to me

being specific to the attached log the question is:

why at 09:26 this is inaccetptable

Dec 1 09:26:29 iulm03 charon: 15[IKE] traffic selectors 172.16.199.11/32|/0[icmp] 172.16.199.0/24|/0 === 10.15.1.18/32|/0[icmp] 10.15.1.0/24|/0 inacceptable

and at 09:30 (only changed debug levels but configuration is the same)

Dec 1 09:30:26 iulm03 charon: 08[CFG] <con1000|1> looking for a child config for 172.16.199.11/32|/0[icmp] 172.16.199.0/24|/0 === 10.15.1.18/32|/0[icmp] 10.15.1.0/24|/0

and child_sa relative to 10.15.1.0/24 gets installed

Probabily I understood that the correct way to solve the original problem is using the largest 10.128.0.0/16 to prevent narrowing and choosing a "wrong" network on my side.

Still I do not understand #7 above...

Still I do not understand #7 above...

That's because config changes don't have an effect on existing connections (in particular with the ipsec.conf/stroke backend and using ipsec reload). The con1000 IKE_SA exists already when the config is reloaded at 09:26 (and again afterwards). So if you add any CHILD_SA configs this won't affect the existing IKE_SA and its old config (no matching CHILD_SA config will be found). At 09:28 the daemon is restarted and the IKE_SA is terminated:

Dec  1 09:28:10 iulm03 charon: 00[IKE] deleting IKE_SA con1000[1] between A.B.C.D[A.B.C.D]...X.Y.Z.W[X.Y.Z.W]

Afterwards the newly established IKE_SA will use the new config and be able to negotiate the CHILD_SA successfully.

I'm quite sure I did not change anything regarding 10.15.1.0/24, at least no voluntarily but probably it was my mistake.

Thank you Tobias for pointing me in the right direction with using the 10.128.0.0/16 (not having control on the remote side and my faulted reasoning based essentially on old IKEv1 sa was the root cause of malfunction).