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 <tob...@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 >