<div dir="ltr">Hi Noel,<div><br></div><div>Thank you for taking time to reply.</div><div><br></div><div>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.</div><div><br></div><div>The server is running Arch Linux, kernel 5.3.13-arch1-1. I'm using systemd-networkd for all network interfaces.</div><div>The Strongswan version is now version 5.8.1 on both machines used for tests.</div><div>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.</div><div>The only sysctl settings set by us at boot are:</div><div>net.ipv4.ip_forward=1<br>net.ipv6.conf.all.forwarding=1<br></div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>I've added both versions of the IP to the local_addrs parameter, and that matches the traffic to the profile as expected:</div><div>local_addrs = <WAN IPv4>, ::ffff:<WAN IPv4><br></div><div><br></div><div>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.</div><div>If you want me to look deeper into it, please let me know.</div><div><br></div><div>Best regards,</div><div>Henrik Juul Pedersen</div><div>LIAB ApS</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 27 Nov 2019 at 11:58, Noel Kuntze <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Henrik,<br>
<br>
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.<br>
<br>
Kind regards<br>
<br>
Noel<br>
<br>
Am 25.11.19 um 12:42 schrieb Henrik Juul Pedersen:<br>
> Hi strongswan users,<br>
> <br>
> 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:<br>
> <br>
> Nov 21 16:11:35 fw01 systemd[1]: Started strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received packet: from 192.168.1.140[500] to <WAN IPv4>[500] (240 bytes)<br>
> 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) ]<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: 192.168.1.140 is initiating an IKE_SA<br>
> 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<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: sending cert request for "C=DK, O=LIAB ApS, CN=<a href="http://liab.dk" rel="noreferrer" target="_blank">liab.dk</a> <<a href="http://liab.dk" rel="noreferrer" target="_blank">http://liab.dk</a>>"<br>
> 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) ]<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: sending packet: from <WAN IPv4>[500] to 192.168.1.140[500] (273 bytes)<br>
> 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)<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: parsed IKE_AUTH request 1 [ EF(1/2) ]<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received fragment #1 of 2, waiting for complete IKE message<br>
> 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)<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: parsed IKE_AUTH request 1 [ EF(2/2) ]<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received fragment #2 of 2, reassembled fragmented IKE message (1864 bytes)<br>
> 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) ]<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received cert request for "C=DK, O=LIAB ApS, CN=<a href="http://liab.dk" rel="noreferrer" target="_blank">liab.dk</a> <<a href="http://liab.dk" rel="noreferrer" target="_blank">http://liab.dk</a>>"<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received 2 cert requests for an unknown ca<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: received end entity cert "C=DK, O=LIAB ApS, CN=equipment3"<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: looking for peer configs matching ::ffff:<WAN IPv4>[<a href="mailto:gateway@liab.dk" target="_blank">gateway@liab.dk</a> <mailto:<a href="mailto:gateway@liab.dk" target="_blank">gateway@liab.dk</a>>]...::ffff:192.168.1.140[<a href="mailto:equipment3@liab.dk" target="_blank">equipment3@liab.dk</a> <mailto:<a href="mailto:equipment3@liab.dk" target="_blank">equipment3@liab.dk</a>>]<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: no matching peer config found<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: peer supports MOBIKE<br>
> Nov 21 16:11:47 fw01 charon-systemd[9507]: generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]<br>
> 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)<br>
> <br>
> The peer config is set up to accept connections to the <WAN IPv4> address only:<br>
> local_addrs = <WAN IPv4><br>
> <br>
> 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).<br>
> <br>
> 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?<br>
> 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.<br>
> <br>
> It would be nice with a note in the peer config documentation, so that others might find these issues faster in the future.<br>
> <br>
> Thanks, and best regards<br>
> Henrik Juul Pedersen<br>
> LIAB ApS<br>
> <br>
> [1] <a href="https://tools.ietf.org/html/rfc3493#section-3.7" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc3493#section-3.7</a><br>
<br>
</blockquote></div>