From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a1) Gecko/20040520 Description of problem: We're using the ipsec wizard in system-network-config. When selecting a configured VPN to activate on boot it does not activate the VPN during the boot up process. Seeing this with i386 and x86_64 platforms. Version-Release number of selected component (if applicable): system-config-network-1.3.17-0 How reproducible: Always Steps to Reproduce: 1.Configure VPN using ipsec wizard, checking the "activate on boot" option 2.Reboot 3. Actual Results: VPN not started during boot. Expected Results: VPN started during boot. Additional info:
hmmm, the initscripts should just do that... is there ONBOOT="yes" in /etc/sysconfig/ifcfg-<ipsec connection name>??
It has recently become quite difficult for us to do any more on this. I have cipe working on another site and since we have to get this site online, we have had to take the machine back to FC1 and are using cipe with it. We had the link operational and had extracted the necessary commands to establish the link and incorporated these into a small bash script - with a view to incorporating this into the rc.local script. But even with the link up and running there is and additional problem with the tunnel where it freezes up all the time. Ping worked but larger packets would not get through. We have not bugzillered this this (should we) and now have limited capacity to debug the problem. Does ipsec actually work for anyone? Having used cipe which "just worked" this has been a fairly painfull experience.
Woops included cipe config by mistake, here is the ipsec config. [stephen@hook etc]$ more sysconfig/network-scripts/ifcfg-CivicCentre DSTGW=xx.x.215.154 SRCGW=xx.x.215.153 DSTNET=192.168.0.0/24 SRCNET=192.168.3.0/24 DST=xx.x.215.154 TYPE=IPSEC ONBOOT=yes SPI_AH_IN=1770128578 SPI_AH_OUT=1715268816 SPI_ESP_IN=521007198 SPI_ESP_OUT=527678539
reassigning to component initscripts
> Ping worked but larger packets would not get through. We have not > bugzillered this this (should we) and now have limited > capacity to debug the problem. Yes, you should bugzilla this. Does it help, if you lower the MTU?
I did read about mtu problems and I cannot remember if I lowered the mtu on the eth device or on the ppp device of the adsl, but it broke stuff, lacking guidance I gave up in Homer Simpson fashion
The problem is, at least from my experience, that the VPN starts before the interfaces are brought up. The VPN therefore doesn't get configured correctly.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
Closing bugs on older, no longer supported, releases. Apologies for any lack of response. Please reopen if this persists on a current release, such as Fedora Core 3.