I've had coworkers report the same issue. The solution was to remove the entire IPSEC section in the XML file (actually, if you know exactly what to remove, you don't need to, but this is the easier more generic way describing the fix). At some point in one of the versions right after the hackathon we accidentally set an empty tunnel in memory which got saved to the config file.
Maybe in the next release we can update config file versions and clear any blank tunnel fields (if someone can send me a known bad config file exhibiting this behaviour). --Bill On 8/17/05, Scott Ullrich <[EMAIL PROTECTED]> wrote: > The problem is the previous version had a parser bug and I bet money > your ipsec profiles are now corrupted. I had to readd my ipsec > connections after the version in question (cannot recall which version > it was). > > The web gui's job is to enforce data but if it becomes corrupted then > it gets rather hard to enforce, no? > > Scott > > > On 8/17/05, Randy B <[EMAIL PROTECTED]> wrote: > > Scott Ullrich wrote: > > > I just tested the latest vpn.inc with my home firewall that has 4+ > > > ipsec links and it works fine. I'll be releasing a new version > > > soon. Please be on the lookout for it and give it a try. > > > > > > Scott > > > > I'm still showing this issue in 0.77. My last fix was to comment out a > > large swath of /etc/inc/filter.inc, but I tried to be a bit more > > pragmatic about it this time, and realized that I came to the precise > > same conclusions that M. Kohn came to. There needs to be some catch, > > some hook in vpn_ipsec.php (line 36 where the empty definition is > > created), filter.inc (see previously submitted patch), or vpn.inc. > > Something somewhere either has to stop making the empty tunnel or > > everything else has to be changed to be able to deal with it. > > > > Scott - you said a change to filter.inc is "not the correct fix", and to > > make it in /etc/inc/vpn.inc. Why would that be? AFAICT, vpn.inc just > > sets up defined tunnels - very little error control in it. The > > specified code chunk in filter.inc (starting ~2093) seems to be the > > flawed one - it just happily chews right over definitions, uncaring > > whether they're empty or not. Shouldn't a process that's generating > > system commands be a bit more concerned about whether or not it's > > putting out proper syntax? > > > > RB > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
