[strongSwan] StrongSwan 5.8.2 - received netlink error: Invalid argument (22)

[Houman]

Hi Tobias,

Thanks again for your help.

I have changed *forceencaps* to *no* in /etc/ipsec.conf, saved and
rebooted.
I still get the same errors. Although the "faking NAT situation to enforce
UDP encapsulation" is not showing anymore. Is this now something else?

Jul  7 00:28:58 de-fsn-6 charon: 12[ENC] generating INFORMATIONAL response
24 [ ]

Jul  7 00:28:58 de-fsn-6 charon: 12[NET] sending packet: from
144.76.11x.xxx[4500] to 2.50.157.xxx[4500] (80 bytes)

Jul  7 00:28:59 de-fsn-6 charon: 11[NET] received packet: from
2001:8f8:xxx:xxx:504c:4f39:258e:8191[4500] to 2a01:4f8:192:xxxx::2[4500]
(144 bytes)

Jul  7 00:28:59 de-fsn-6 charon: 11[ENC] parsed INFORMATIONAL request 11 [
N(UPD_SA_ADDR) N(NATD_S_IP) N(NATD_D_IP) ]

Jul  7 00:28:59 de-fsn-6 charon: 11[IKE] local host is behind NAT, sending
keep alives

Jul  7 00:28:59 de-fsn-6 charon: 11[KNL] received netlink error: Invalid
argument (22)

Jul  7 00:28:59 de-fsn-6 charon: 11[KNL] unable to update SAD entry with
SPI cf20af06

Jul  7 00:28:59 de-fsn-6 charon: 11[KNL] received netlink error: Invalid
argument (22)

Jul  7 00:28:59 de-fsn-6 charon: 11[KNL] unable to update SAD entry with
SPI 0b13a954

Jul  7 00:28:59 de-fsn-6 charon: 11[ENC] generating INFORMATIONAL response
11 [ N(NATD_S_IP) N(NATD_D_IP) ]

Jul  7 00:28:59 de-fsn-6 charon: 11[NET] sending packet: from
2a01:4f8:xxx:732c::2[4500] to 2001:8f8:xxx:53d3:504c:4f39:xxx:8191[4500]
(128 bytes)

Jul  7 00:28:59 de-fsn-6 charon: 01[KNL] creating acquire job for policy
128.116.xxx.3/32[tcp/https] === 10.10.18.xxx/32[tcp/56633] with reqid {2595}

Jul  7 00:28:59 de-fsn-6 charon: 01[CFG] trap not found, unable to acquire
reqid 2595

Jul  7 00:29:00 de-fsn-6 charon: 06[NET] received packet: from
2001:8f8:1163:xxxx:504c:4f39:258e:8191[4500] to 2a01:4f8:xxx:xxxx::2[4500]
(144 bytes)

Jul  7 00:29:00 de-fsn-6 charon: 06[ENC] parsed INFORMATIONAL request 11 [
N(UPD_SA_ADDR) N(NATD_S_IP) N(NATD_D_IP) ]

Jul  7 00:29:00 de-fsn-6 charon: 06[IKE] received retransmit of request
with ID 11, retransmitting response

Jul  7 00:29:00 de-fsn-6 charon: 06[NET] sending packet: from
2a01:4f8:192:xxxx::2[4500] to 2001:8f8:1163:53d3:504c:xxxx:258e:8191[4500]
(128 bytes)

Jul  7 00:29:01 de-fsn-6 charon: 15[IKE] retransmit 5 of request with
message ID 0


It is very strange that the same configuration works with StringSwan 5.7.2
but 5.8.2 throws these errors. Something must have changed that I'm
missing, I think.
If you see no other possibility, I suppose I have no other choice than
disabling IPV6 by setting *use_ipv6 = no* in
*/etc/strongswan.d/charon/socket-default.conf*

I was hoping not to do it, as some ISP might only support IPv6 and by doing
that I might cause new problems. What do you think?  Maybe I should live
with that error. After all, it happens only 5 times a day. What is the most
sensible thing to do?

Many Thanks,
Houman

On Mon, 6 Jul 2020 at 11:12, Tobias Brunner <tobias at strongswan.org> wrote:

> Hi Houman,
>
> > I could disable *forceencaps=no* but having it enabled helps overcoming
> > restrictive firewalls.  So maybe it's better for my users if I
> > disabled IPv6 instead. Do you agree?
> > Or is forcing it not such a big deal after all?
>
> Depends on the clients.  Many will be behind a NAT anyway, others (e.g.
> our Android client) will also force UDP encapsulation.  Only for
> unnatted clients behind restrictive firewalls that can't force it
> themselves, will forcing it on the server make a difference.
>
> > What is strange is that I thought I had disabled ipv6, like this:
> > ...
> > net.ipv6.conf.all.disable_ipv6 = 1
> > net.ipv6.conf.default.disable_ipv6 = 1
>
> I don't think that affects interfaces that are already up, so you might
> have to explicitly set it for the specific interface too.
>
> > Where do I disable it then?
>
> You may disable charon.plugins.socket-default.use_ipv6 so the plugin
> won't open an IPv6 socket.
>
> Regards,
> Tobias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200707/cb5775be/attachment.html>