[strongSwan] Peer configs not matching IPv4-mapped IPv6

[Noel Kuntze]

Hello Henrik,

strongSwan listens on the IPv4 wildcard address, too, so how did this peculiar situation come to pass? strongSwan configures the Linux kernel's network settings, too and unless they can deal with such a use case correctly, trying to somehow deal with this situation is pointless.

Kind regards

Noel

Am 25.11.19 um 12:42 schrieb Henrik Juul Pedersen:
> Hi strongswan users,
> 
> I've recently stumbled upon a configuration issue on one of my VPN servers (running Strongswan version 5.8.0), that I had a hard time identifying. I could read the following from the journal:
> 
> Nov 21 16:11:35 fw01 systemd[1]: Started strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received packet: from 192.168.1.140[500] to <WAN IPv4>[500] (240 bytes)
> Nov 21 16:11:47 fw01 charon-systemd[9507]: parsed 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) ]
> Nov 21 16:11:47 fw01 charon-systemd[9507]: 192.168.1.140 is initiating an IKE_SA
> Nov 21 16:11:47 fw01 charon-systemd[9507]: selected proposal: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/CURVE_25519
> Nov 21 16:11:47 fw01 charon-systemd[9507]: sending cert request for "C=DK, O=LIAB ApS, CN=liab.dk <http://liab.dk>"
> Nov 21 16:11:47 fw01 charon-systemd[9507]: generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
> Nov 21 16:11:47 fw01 charon-systemd[9507]: sending packet: from <WAN IPv4>[500] to 192.168.1.140[500] (273 bytes)
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received packet: from ::ffff:192.168.1.140[4500] to ::ffff:<WAN IPv4>[4500] (1244 bytes)
> Nov 21 16:11:47 fw01 charon-systemd[9507]: parsed IKE_AUTH request 1 [ EF(1/2) ]
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received fragment #1 of 2, waiting for complete IKE message
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received packet: from ::ffff:192.168.1.140[4500] to ::ffff:<WAN IPv4>[4500] (700 bytes)
> Nov 21 16:11:47 fw01 charon-systemd[9507]: parsed IKE_AUTH request 1 [ EF(2/2) ]
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received fragment #2 of 2, reassembled fragmented IKE message (1864 bytes)
> Nov 21 16:11:47 fw01 charon-systemd[9507]: parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR DNS) 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) ]
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received cert request for "C=DK, O=LIAB ApS, CN=liab.dk <http://liab.dk>"
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received 2 cert requests for an unknown ca
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received end entity cert "C=DK, O=LIAB ApS, CN=equipment3"
> Nov 21 16:11:47 fw01 charon-systemd[9507]: looking for peer configs matching ::ffff:<WAN IPv4>[gateway at liab.dk <mailto:gateway at liab.dk>]...::ffff:192.168.1.140[equipment3 at liab.dk <mailto:equipment3 at liab.dk>]
> Nov 21 16:11:47 fw01 charon-systemd[9507]: no matching peer config found
> Nov 21 16:11:47 fw01 charon-systemd[9507]: peer supports MOBIKE
> Nov 21 16:11:47 fw01 charon-systemd[9507]: generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
> Nov 21 16:11:47 fw01 charon-systemd[9507]: sending packet: from ::ffff:<WAN IPv4>[4500] to ::ffff:192.168.1.140[4500] (88 bytes)
> 
> The peer config is set up to accept connections to the <WAN IPv4> address only:
> local_addrs = <WAN IPv4>
> 
> Now, it seems, that strongswan thinks that ::ffff:<IPv4> is different from <IPv4> (which, as far as I read the RFC[1], it should not).
> 
> Whether strongswan should translate IPv4-mapped IPv6 to plain IPv4 is not for me to decide, but I would like some advice on how I should configure my settings, to account for these situations, do I add all IPv4 addresses as both plain and mapped?
> My solution on this specific server has been to just disable IPv6 in strongswan, as it is not needed at the moment, however I might have to use it in the future.
> 
> It would be nice with a note in the peer config documentation, so that others might find these issues faster in the future.
> 
> Thanks, and best regards
> Henrik Juul Pedersen
> LIAB ApS
> 
> [1] https://tools.ietf.org/html/rfc3493#section-3.7

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191127/1767918f/attachment.sig>