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

[Houman]

Hi Tobias,

Thank you so much for the detailed explanation. You brought up some
interesting points.

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?

What is strange is that I thought I had disabled ipv6, like this:

*/etc/sysctl.conf*
net.ipv4.ip_forward = 1
net.ipv4.ip_no_pmtu_disc = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Where do I disable it then?

Many Thanks,
Houman

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

> Hi Houman,
>
> > We have two types of servers. Same users are doing ok on servers with
> > StrongSwan 5.7.2 on kernel  5.3.0-53-generic.
> >
> > But on the servers with StrongSwan 5.8.2 with kernel* 5.4.0-39-generic,
> > *the issue arises. (Not for all users, but quite a few)
>
> I had a closer look at the log and now saw what the problem is.  It has
> nothing to do with the strongSwan or kernel version.
>
> The problem is that the client moves from an IPv4 address to an IPv6
> address and you apparently have UDP-encapsulation forced (see the
> "faking NAT situation to enforce UDP encapsulation").  However, the
> Linux kernel currently does not support UDP encapsulation for IPv6 (the
> upcoming 5.8 kernel will be the first one with support for it), so you
> get that error when the daemon tries to replace the IPv4 SA with an IPv6
> SA that has UDP encapsulation enabled.  Try without forcing UDP
> encapsulation (or disable IPv6 in the socket-default plugin if you don't
> want clients to use it).
>
> Regards,
> Tobias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200706/71c8f51e/attachment-0001.html>