Bug 481529 - IPSEC works porly with 2 links
IPSEC works porly with 2 links
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-25 20:58 EST by Need Real Name
Modified: 2011-10-11 14:04 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-11 14:04:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2009-01-25 20:58:37 EST
I have two VPN links.
If I use "Script 1" to establish VPN for any of two links
everything works more or less OK.
When I use "Script 2" to establish both VPN links 
simultaneously - they get established OK,
and VPN works in terminal SSH and to copy small files.

Then, when I try to copy a large (20Mbytes) file
over VPN link 2 ($RENOTE_NETW2) the VPN connection stalls after 
about 5Mb data transfer. The only way to fix- restart racoon.
In the same time there is no problem to transfer large files
over VPN link 1 ($RENOTE_NETW). A data of any size can be transferred to $RENOTE_NETW.
Again, there is no such problem when starting just a single VPN link,
not two simultaneously.
ipsec-tools-0.7.1-7.fc9.x86_64
tested F9 & F10:
Linux comp2 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Linux comp 2.6.27.9-73.fc9.x86_64 #1 SMP Tue Dec 16 14:54:03 EST 2008 x86_64 x86_64 x86_64 GNU/Linux




In general IPSEC in linux is very poor & annoying.
In addition to this problem - Linux IPSEC drops connection all the time,
and dead peer detection does not work at all.
(for example - reboot remote router. VPN will be dead.
The only way to re-establish it is to restart racoon)
see https://bugzilla.redhat.com/show_bug.cgi?id=467789 for another bug
Linux IPSEC is of horrible quality and need to be replaced by something better written. BSD IPSEC is so much more reliable & stable.



==============Script 1 - establish a single VPN link
echo "flush; spdflush;
        spdadd $VIRTUAL_IP_ADDR/24 $RENOTE_NETW any
            -P out ipsec esp/tunnel/$LOCAL_PUBLIC_ADDR-$VSU_ADDR/require ;
        spdadd $RENOTE_NETW $VIRTUAL_IP_ADDR/24 any
            -P in ipsec esp/tunnel/$VSU_ADDR-$LOCAL_PUBLIC_ADDR/require ;" \
        | setkey -c

/sbin/route add -net $RENOTE_NETW gw $VIRTUAL_IP_ADDR
racoon -F -d -d -d
============ End of Script 1

==============Script 2 - establish two VPN links simultaneously

echo "flush; spdflush;
        spdadd $VIRTUAL_IP_ADDR/24 $RENOTE_NETW any
            -P out ipsec esp/tunnel/$LOCAL_PUBLIC_ADDR-$VSU_ADDR/require ;
        spdadd $RENOTE_NETW $VIRTUAL_IP_ADDR/24 any
            -P in ipsec esp/tunnel/$VSU_ADDR-$LOCAL_PUBLIC_ADDR/require ;
        spdadd $VIRTUAL_IP_ADDR/24 $RENOTE_NETW2 any
            -P out ipsec esp/tunnel/$LOCAL_PUBLIC_ADDR-$VSU_ADDR2/require ;
        spdadd $RENOTE_NETW2 $VIRTUAL_IP_ADDR/24 any
            -P in ipsec esp/tunnel/$VSU_ADDR2-$LOCAL_PUBLIC_ADDR/require ;" \
        | setkey -c
/sbin/route add -net $RENOTE_NETW gw $VIRTUAL_IP_ADDR
/sbin/route add -net $RENOTE_NETW2 gw $VIRTUAL_IP_ADDR
racoon -F -d -d -d
============ End of Script 2
Comment 1 Need Real Name 2009-01-25 21:06:58 EST
just tries it again - 3472KB transferred and the connection to $RENOTE_NETW2 is dead.
No problem with $RENOTE_NETW
Comment 2 Need Real Name 2009-01-25 21:19:35 EST
tried again: 3728KB transferred and VPN link is dead.
Comment 3 Need Real Name 2009-01-25 21:20:22 EST
tried again: 3728KB transferred and VPN link is dead.
Comment 4 Need Real Name 2009-01-26 20:09:38 EST
The IPSEC DPD messages continue to go, but the link itself is dead.
Looks something is wronk with kernel routing code.

2009-01-26 20:08:18: DEBUG: DPD R-U-There-Ack received
2009-01-26 20:08:18: DEBUG: received an R-U-THERE-ACK
Comment 5 Need Real Name 2009-01-26 20:25:46 EST
The problem may somehow be related to some network buffers.
Initially, when the second connection still works,
the ssh shows unrealistically high speed (>1Mb/sec) what is well above 
the actual link speed. Looks the data is copied to some buffer,
and do not go further.
Comment 6 Need Real Name 2009-07-27 04:23:20 EDT
same problem with 
ipsec-tools-0.7.2-2
from
http://download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/
Comment 7 Need Real Name 2009-09-26 15:56:22 EDT
same problem with 
Linux comp 2.6.30.5-43.fc11.x86_64 #1 SMP Thu Aug 27 21:39:52 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
ipsec-tools-0.7.2-1.fc11.x86_64
Comment 8 Need Real Name 2009-11-18 08:33:53 EST
F12 same problem
Comment 9 Bug Zapper 2010-11-04 07:32:44 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bug Zapper 2010-12-05 02:02:15 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 11 Need Real Name 2010-12-06 15:09:20 EST
same problem with F14
Comment 12 Need Real Name 2010-12-06 15:09:38 EST
same problem with F14
Comment 13 Dave Jones 2011-10-11 14:04:44 EDT
I suspect to see any kind of change in behaviour in this, you'll need to bring this up directly with the upstream networking maintainers. You can find them at netdev@vger.kernel.org

Note You need to log in before you can comment on or make changes to this bug.