[strongSwan] Peer configs not matching IPv4-mapped IPv6

Wed Nov 27 13:13:14 CET 2019

Hi Noel,

Thank you for taking time to reply.

I've never seen this kind of translation before, so I'm not sure why it
happens. Since collecting the output from my original post, I've been able
to update the server, and the situation is exactly the same.

The server is running Arch Linux, kernel 5.3.13-arch1-1. I'm using
systemd-networkd for all network interfaces.
The Strongswan version is now version 5.8.1 on both machines used for tests.
Both interfaces used on the server has both IPv4 and IPv6 addresses,
however only an IPv4 address is set on the client (192.168.1.140), and none
of the IPv6 addresses are shown in any logs.
The only sysctl settings set by us at boot are:
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

What is confusing me the most, is that the initial communication on port
500 is okay, but once continued on port 4500 it is mapped to IPv6.
I've looked through my firewall settings, and I don't have any translations
based on ports, and none between IPv4 and IPv6. So as far as I can tell, if
it's something in the firewall, the issue should also be seen on port 500.

I've added both versions of the IP to the local_addrs parameter, and that
matches the traffic to the profile as expected:
local_addrs = <WAN IPv4>, ::ffff:<WAN IPv4>

I just wanted to share my experience with you, and to hear whether anyone
has experienced a similar issue? As I believe our setup is nothing out of
the ordinary.
If you want me to look deeper into it, please let me know.

Best regards,
Henrik Juul Pedersen
LIAB ApS

On Wed, 27 Nov 2019 at 11:58, Noel Kuntze
<noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191127/3b06aa98/attachment.html>