> On May 31, 2015 at 1:14 AM "jsulli...@opensourcedevel.com"
> wrote:
>
>
>
>
> > On May 30, 2015 at 10:42 PM "jsulli...@opensourcedevel.com"
> > wrote:
> >
> >
> > > On May 30, 2015 at 6:01 PM Noel Kuntze wrote:
> > >
> > >
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> >
> On May 30, 2015 at 10:42 PM "jsulli...@opensourcedevel.com"
> wrote:
>
>
> > On May 30, 2015 at 6:01 PM Noel Kuntze wrote:
> >
> >
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Hello John,
> >
> > It is likely that that is caused by insufficient crypto
> >
> On May 30, 2015 at 6:01 PM Noel Kuntze wrote:
>
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello John,
>
> It is likely that that is caused by insufficient crypto
> processing capabilities on either side, so packets need to be dropped,
> as the transmit/receive buffers are full
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello John,
It is likely that that is caused by insufficient crypto
processing capabilities on either side, so packets need to be dropped,
as the transmit/receive buffers are full.
A solution to this problem is to distribute the work load
over seve
Hello, all. We are attempting to use StrongSWAN on a fast (1 Gbps CIR one side
and 4x10Gbps on the other) with about 80ms latency so pretty high bandwidth
delay product. The traffic is GRE/IPSec. Our benchmarks show we can saturate
the 1 Gbps side with just GRE sustaining high 800 low 900 Mbps.
Hello, all. I'm working on a fairly complex setup where we are doing
ingress traffic shaping with an IFB interface including traffic
transported via GRE/IPSec on gateways using keepalived for VRRP.
We would normally use IPSec in transport mode for GRE/IPSec but that
seems to prevent the tc filter
I can confirm this bug on strongSwan 5.3.0 from Homebrew and OSX 10.10.3
Submited new bug report https://wiki.strongswan.org/issues/974
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Hello,
I just thought I'd point out that the documentation for ipsec.conf seems to be
incorrect. Either that or I'm mis-reading it.
It suggests that closeaction is only applicable to IKEv2. However, I've been
testing it with IKEv1 using the hold action in the event that the peer sends a
dele
It works! Thank you Noel!
The key is to set up a pass-through connection in Strongswan's own
ipsec.conf configuration file. No mucking with Linux kernel routing or
XFRM policy guts needed.
conn my_precious_lan
leftsubnet=172.31.0.0/16
rightsubnet=172.31.0.0/16
authby=never
type=pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello Alan,
Remedy #2 is your salvation.
The ipsec.conf files of the test scenarios I linked to
have example passthrough policy definitions.
Look at those. I think things will be much clearer then.
Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze
Thanks Zhuyj and Noel, I am a bit more enlightened and closer. I'm
still a little lost, working with the guts of Linux routing is quite
new to me.
Linux can have multiple routing tables, identified by a number. "220"
is just the number chosen by Strongswan to insert its new route.
"route" apparent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
strongSwan builds policy based tunnels. XFRM policies are used to steal the
packets from
the kernel after the routing decision. You need to write a passthrough policy
that matches the traffic in your LAN to except it from the policy of
your
This route should be inserted in route table 220
发自我的 iPhone
> 在 2015年5月30日，14:00，Alan Tu <8li...@gmail.com> 写道：
>
> Hmmm, I don't think this worked. The pre- and post-VPN routing tables
> are actually identical:
>
> $ route -n
> Kernel IP routing table
> Destination Gateway Genmas
13 matches
Mail list logo
