[strongSwan] A bug of nat-virtua-ip ?

[kenxin lau]

Hi,all

    I set up a test platform just as the test example  of  "strongSwan UML
Tests/ikev2/nat-virtual-ip ".This is  the  detail of testing platform which
I used  :
moon :
    cpu: 333 MHz PowerPC
    RAM memory: DDR2 256 MB
    software: Linux 2.6.32 ,strongswan-4.5.2, iptables-1.4.5
SUN ：
    cpu: 3 GHz x86
    RAM memory: DDR2 3 GB
    software: Linux 2.6.32 ,strongswan-4.5.2
Alice, bob :
    cpu: 3 GHz x86
    RAM memory: DDR2 3 GB
    software: Linux 2.6.32 ,strongswan-4.5.2

   All the configuration script I used is the same as the example
"strongSwan UML Tests/ikev2/nat-virtual-ip ".
   The router moon set up a connection to gateway sun,  and the gateway sun
had assigned a virtual IP address to router moon. A special updown script
on moon specified by leftupdown=/etc/nat_updown dynamically inserted a
source NAT rule which mapped the IP address of client alice to the virtual
IP of moon.
  Then the client alice  send  the udp packets of 100 bytes length every 10
microseconds  with about 10 threads at one time .   Under these
circumstances ,  the  idle of moon's CPU would be less than 10%, even 0% .
As a result , the moon could not printf anything. If the router moon PING
the client alice at the same time, there would  appear a big time delay
 which was above 10 seconds.
    I had ever  thinking that  this phenomena might be arisen from the low
performance of moon'CPU.So I aslo did two experiments. The first
experiment, I used the same hardware platform to set up the environment as
the example of  "Test ikev2/net2net-psk" and found what would happen. The
result is that  the  idle of moon's CPU would be  more than 90% all the
time and there was not any big time delay when the router moon PING the
client alice at the same time ,which was fewer than 1 microseconds all the
time.
   The second experiment,  I used the same hardware platform to set up a
 environment which just set up the NAT and  open the ip_forward in the
moon. And the udp packets of alice sent out to the gateway sun only through
the NAT of moon. The result is  that  the  idle of moon's CPU would be
 more than 95% all the time and there was not any big time delay when the
router moon PING the client alice at the same time, which was fewer than 1
microseconds all the time .
  This two experiment had approved that the "big time delay" phenomena was
not arisen from  the low performance of moon'CPU. They were both working
well when the NAT was separated from the IPSEC. But when joined the NAT and
IPSEC together in the moon, the moon could not work normally. why ? Is this
 a bug of the strongswan or the NAT ?

 Regards ,


                                                         Kenxin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120531/04d3cc15/attachment.html>