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]
