Bingo! Forwarding was disabled and things were working again with:
# modprobe iptable_nat
# echo 1 /proc/sys/net/ipv4/ip_forward
Aaron
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
On 2015-03-11 10:35, Martin Willi wrote:
Hi,
Is it essential for both nodes to receive all the ESP packets?
Yes.
Cannot be ESP sequence numbers synchronized through the HA plugin?
No, this is not how the HA plugin works. ESP sequence numbers move very
fast, making a synchronization in
On 12/03/2015 08:29, Martin Willi wrote:
IKEv2 fragmentation is a protocol extension (RFC 7383), and AFAIK it is
not supported in the Windows client. So you can't use it with these
clients, but have to try to avoid messages larger than your MTU to get
things working on such constrained networks.
VPN client server running StrongSwan v5.2.2. Both OSes Centos 6.6.
An IKEv2 IPsec tunnel has been up for a couple days with the client initiating
a ping, once per minute, of the same host behind the VPN gateway. This is the
only application level traffic on the tunnel.
Roughly every two
On 03/12/2015 11:16 AM, Noel Kuntze wrote:
Hello Ken,
It is dependent on the IKE version.
Quote from the man page:
reauth = yes | no
whether rekeying of an IKE_SA should also reauthenticate the
peer. In IKEv1, reauthentication is always done. In
Hi,
As per the description of vulnerabilities in above links, the
vulnerability is only applicable and will lead to crash in pluto IKE
daemon alone. Charon is not mentioned.
You should apply these fixes even if using charon only, the
libstrongswan code is used by charon. Not sure where this
Hi Tom,
Is there a reason that, when using two Strongswan endpoints, one would
not choose reauth=no?
Yes. Reauthentication re-evaluates authentication credentials, checks
the certificate status or rechecks permissions in the AAA backend.
IKE_SA rekeying, as used with reauth=no, only refreshes
