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>[[email protected] > <mailto:[email protected]>]...::ffff:192.168.1.140[[email protected] > <mailto:[email protected]>] > 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
signature.asc
Description: OpenPGP digital signature
