Hello Patricia,
release candidate 2 is available which includes Tobias' patches:
http://download.strongswan.org/strongswan-4.5.3rc2.tar.bz2
Regards
Andreas
On 07/28/2011 05:49 PM, Tobias Brunner wrote:
Hi Patricia,
it seems that some packets leave the tunnel during the handover
Hi Tobias
Thanks for the reply.
No, i did not know of the load-tester plugin till you told me about it. I
followed your advice and started setting up the load-tester plugin with
strongswan-4.5.2 on Linux-Fedora servers
- As mentioned in one of the mail-list on Load-Tester plugin, I have
Hi,
- What is the meaning of initiators=10 and iterations=100. i would
think that for simulating establishment of 1000 simultaneous tunnels i
would want 1000 initiators to be running right? Why only 10 and
running them 100 times?
initiators defines the number of threads. Each thread
Hi Patricia,
I've tested strongswan-4.5.3rc2 and I still get the same behaviour.
I'm testing MOBIKE by sending CBR traffic from the initiator at a
rate of 45Kbps.
When I deactivate eth0 I obtain the behavior that you can see on one.png.
Then, I activate eth0 again and deactivate eth1
hi Tobias,
On 29 July 2011 15:58, Tobias Brunner tob...@strongswan.org wrote:
Hi Patricia,
I've tested strongswan-4.5.3rc2 and I still get the same behaviour.
I'm testing MOBIKE by sending CBR traffic from the initiator at a
rate of 45Kbps.
When I deactivate eth0 I obtain the
Hi Patricia,
I've test also with virtual IP's and I obtain the same behaviour :(
Ah, yes. The source route installed by charon only covers eth0 and its
default gateway.
Andreas, Martin, any ideas?
Regards,
Tobias
___
Users mailing list
Would it help to bind the virtual IP do a dummy interface, so that
when the physical interface goes away the source route still
exists and remains covered by the traffic selectors and thus by
the transient DROP policy for the TS.
Regards
Andreas
On 07/29/2011 04:12 PM, Tobias Brunner wrote:
Hi
Hello Patricia,
binding the virtual IP to a dummy interface currently isn't
supported by strongSwan. It was just a suggestion for a
possible future option.
A workaround that you could implement is to activate
iptables with a default DROP policy, open the firewall to
UDP/500, UDP/4500 and ESP,
iptables -A INPUT -m policy --dir in --pol ipsec --proto esp -j ACCEPT
iptables -A OUTPUT -m policy --dir out --pol ipsec --proto esp -j ACCEPT
Thus no plaintext packets should leave the VPN endpoint.
That's probably the best solution for now. The problem with the virtual
IP approach is
Hi Tobias,
Many thanks for your response. It works like a charm.
It turns out the table number is 12 so I can't test the patch. From
rt_tables the main table is 255. Can you have table number higher than main?
Just wondering.
Best Regards,
Simon
- Original Message -
From: Tobias
10 matches
Mail list logo
