Re: [pfSense Support] Alert about pf rules syntax errors... again...
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]
Re: [pfSense Support] Alert about pf rules syntax errors... again...
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]
Re: [pfSense Support] Alert about pf rules syntax errors... again...
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]
Re: [pfSense Support] Alert about pf rules syntax errors... again...
This is not the correct fix. Try this /etc/inc/vpn.inc.
http://pfsense.com/cgi-bin/cvsweb.cgi/pfSense/etc/inc/vpn.inc?rev=1.69;content-type=text%2Fplain
On 8/12/05, M. Kohn [EMAIL PROTECTED] wrote:
Hi,
small hint abut IPSec bug (I hope...):
(pfSense 0.75)
The function filter_rules_generate() in
/etc/inc/filter.inc rules will try to set
the rules for IPSec:
Line 2093 in /etc/inc/filter.inc:
---
if(is_array($config['ipsec']['tunnel'])) {
foreach ($config['ipsec']['tunnel'] as $tunnel) {
$remote_gateway = $tunnel['remote-gateway'];
---
Normally no problem, but there is an empty tunnel definition
in $config['ipsec']['tunnel'], but I don't know why...
So I added the following patch as a workaround, checking if
$tunnel['remote-gateway'] is empty:
(see attached filter.diff)
PS: Should I better use CVSTRAC for such things?
--- filter.inc.org Fri Aug 12 12:56:44 2005
+++ filter.inc Fri Aug 12 16:11:20 2005
@@ -2091,6 +2091,7 @@
}
if(is_array($config['ipsec']['tunnel'])) {
foreach ($config['ipsec']['tunnel'] as $tunnel) {
+ if (!empty($tunnel['remote-gateway'])) {
$remote_gateway = $tunnel['remote-gateway'];
$local_subnet =
return_vpn_subnet($tunnel['local-subnet']);
$ipfrules .= pass quick on . $wanif . proto udp
from . $ipsec_ip . to . $remote_gateway . port = 500 keep state label
\IPSEC: . $tunnel['descr'] . udp\\n;
@@ -2104,6 +2105,7 @@
$ipfrules .= pass quick on . $lanif . from .
$tunnel['remote-subnet'] . to . $local_subnet . keep state label
\IPSEC: . $tunnel['descr'] .\\n;
$ipfrules .= pass quick on . $lanif . from .
$local_subnet . to . $tunnel['remote-subnet'] . keep state label
\IPSEC: . $tunnel['descr'] .\\n;
+ }
}
}
-
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]
