What you say...Noel Kuntze (n...@familie-kuntze.de):
> On 05.01.2017 20:31, Hose wrote:
> > So from what I can tell each time it's doing an IKE re-key it's creating an
> > additional set of SAs. Any idea why this is occurring?
> Try disabling reauthentication and/o
What you say...Noel Kuntze (n...@familie-kuntze.de):
> On 03.01.2017 20:51, hose wrote:
> > I'm pasting the logs below since they're quite long even though they're
> > the past 10 minutes. If you notice it's rekeying and deleting SAs quite
> > often.
>
I'm currently running a fairly large network of hosts connected to each
other in transport mode running strongswan 5.2.1 on Debian stable. A
number of GRE tunnels run between all the hosts, with OSPF on top of the
GRE tunnels to handle all the routing. It all works fine except for one
thing: Inste
What you say...Martin Willi (mar...@strongswan.org):
>
>
> >(one of which is quite old - running a dual core netburst
> >P4 @2.8, the other two are VMs on decent hardware, all of which have no
> >load) are hitting walls at 300mb/s
> On a Netburst architecture you can't expect more; it does not h
nel so I could use it to troubleshoot
the other tunnels / hardware. I feel like a bog standard VM with no
resource contention and no local load would be able to push at least
500mb/s without too much tweaking.
hose
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
may help, but that's just
speculation.
hose
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
What you say...Hose (hose+strongs...@bluemaggottowel.com):
> What you say...Noel Kuntze (n...@familie-kuntze.de):
>
> > Hello Hose,
> >
> > > To keep crypto overhead down the IPsec tunnels are constructed in
> > > transport mode with aes128/sha1 for IKE and a
What you say...Noel Kuntze (n...@familie-kuntze.de):
> Hello Hose,
>
> > To keep crypto overhead down the IPsec tunnels are constructed in
> > transport mode with aes128/sha1 for IKE and aes128/md5 for IPsec;
> aes128-sha1 and aes128-md5 are not really the optimum.
> Tr
the unencrypted
throughput. The only thing I haven't done is migrate over to IKEv2
which is on the roadmap but haven't implemented yet due to some legacy
requirements, however I can't imagine that would actually effect
throughput as that seems to be a kernel bottleneck.
hose
__
