Bug #4237
closed
Error "macro IPsec not defined" once after firmware upgrade
Added by Pi Ba almost 10 years ago.
Updated over 7 years ago.
Description
Error "macro IPsec not defined"
I dont know why it currently happens, and dont have a way to trigger it easily as it only seems to happen when perform a firmware upgrade. I currently can consistently trigger this error by upgrading with 'pfSense-Full-Update-2.2-RC-amd64-20150116-1153'.
Iv'e seen it before where there was an error in my aliases.. https://redmine.pfsense.org/issues/4185
Now it only happens during first boot after a firmwareupgrade..
I did manage to once see the rules.debug file and could see almost none of the aliases where written.. Only the loopback one.. (see attached screenshot)
There seem to be no relevant errors in system.log , nor any php / crash reports when logging in..
Files
- Status changed from New to Feedback
- Target version changed from 2.2 to 2.2.1
- Affected Version deleted (
2.2)
seems likely there is some other root cause, like the alias issue from before, given no one else appears to be seeing this.
- Target version deleted (
2.2.1)
still no other reports of this. will leave for feedback for now.
Having the same issue here:
[ There were error(s) loading the rules: /tmp/rules.debug:108: macro IPsec not defined - The line in question reads [108]: pass out on $IPsec all tracker 1000000961 tracker 1000000962 keep state label IPsec internal host to host]
2.2.3-RELEASE (amd64)
built on Tue Jun 23 16:37:42 CDT 2015
FreeBSD 10.1-RELEASE-p13
I believe this happens when config.cache is corrupt or truncated because of power loss shortly after writing the file. The changes we made earlier today in 2.2.4 and newer will prevent that from occurring if that is the root cause.
If anyone has a reliable means of replicating this, we'd definitely like to know how. Seems it's happened to a handful of people, so not common, but haven't seen it myself and no one who has seemed to find it replicable.
This is still happening as of 2.2.5-RELEASE
It went away for a while, but came back after I tried to setup pfsense to connecto to an ipsec server. Trying to come up wiht a better way to reproduce this, but for now, that is all I have.
Also: is there a way to "clear out" this issue for now?
FWIW: I did not have a power outage any time recently or any other un-clean reboot.
I have this problem as well.
But I dont know if it causes any problems at all?
There were error(s) loading the rules: /tmp/rules.debug:108: macro 'IPsec' not defined - The line in question reads [108]: pass out on $IPsec all tracker 1000000961 tracker 1000000962 keep state label "IPsec internal host to host"
2.2.5-RELEASE (amd64)
built on Wed Nov 04 15:49:37 CST 2015
FreeBSD 10.1-RELEASE-p24
In fact I started to get this error messages after the ESX host with pfsense-vm crashed hard.
I have the same issue and it seems it is breaking the IPSec tunnels stability. I upgraded from 2.1 to 2.2.6.
php-fpm242: /rc.filter_configure_sync: New alert found: There were error(s) loading the rules: /tmp/rules.debug:107: macro 'IPsec' not defined - The line in question reads [107]: pass out on $IPsec all tracker 1000000961 tracker 1000000962 keep state label "IPsec internal host to host"
Hello to Everyone.
I have the same problem after upgrade to 2.2.6
01-12-16 13:00:25 [ There were error(s) loading the rules: /tmp/rules.debug:109: macro IPsec not defined - The line in question reads [109]: pass out on $IPsec all tracker 1000000961 tracker 1000000962 keep state label IPsec internal host to host]
2.2.6-RELEASE (amd64)
built on Mon Dec 21 14:50:08 CST 2015
FreeBSD 10.1-RELEASE-p25
I have the same issue after upgrade to 2.2.6
There were error(s) loading the rules: /tmp/rules.debug:108: macro 'IPsec' not defined - The line in question reads [108]: pass out log on $IPsec all tracker 1000000961 tracker 1000000962 keep state label "IPsec internal host to host"
If i disable IPsec completely (incl. delete all related rules), as i am not using it anymore...the problem jumps over to:
There were error(s) loading the rules: /tmp/rules.debug:112: macro 'ipAlias' not defined - The line in question reads [112]: pass quick inet proto { tcp udp } from $ipAlias to 111.111.111.111 port 53 tracker 1435336776 keep state label "USER_RULE"
- Affected Architecture added
- Affected Architecture deleted (
amd64)
I believe the issue described here is just during the first filter reload during boot post-upgrade. I've never seen a way in the code to end up in this situation, and have no means of replicating. As much of the ruleset as you have in place, it can't be that it's completely failing to read the config, but the only way it'd miss the IPsec macro is if $config['ipsec']['enable'] isn't set. But if that isn't set, it won't add the firewall rules that trigger the error. It should be impossible to get one without the other. Maybe the issue is in pf somehow. Without having a replicable case it's hard to say.
Subsequent filter reloads during boot post-upgrade are fine so the system is still functioning normally when it finishes booting. While ugly and an indication there is some bug to fix there, the single notification is harmless.
If you get repeated notices, that's a problem.
Fabian: doesn't seem like the same issue in that case, this goes away post-boot. That's still happening while the system's running?
Chris: yes, it's still happening while the system is running. looks like some kind of race-condition to me, as
pfctl -nf /tmp/rules.debug
runs fine every time i test it manually. but the
macro 'IPsec' not defined
is an error produced by
pfctl
I obeserved /tmp/rules.debug every 0.5 seconds with pfctl -nf /tmp/rules.debug
and copied rules.debug to rules.debug.broken in case of exit code is not equal 0.
After less than 30 minutes i got a rules.debug.broken.
In rules.debug.broken there are NOT:
- #System aliases (the only one: loopback = "{ lo0 }")
- #Snort tables
table <bogonsv6> persist file "/etc/bogonsv6"
table <vpn_networks>
table <negate_networks> (this is still there, but no {} with networks)
- # User Aliases (completely gone, except for section header)
- # Gateways (completely gone, except for section header)
- All "scrub on $WAN all fragment reassemble" (for $WAN, $LAN, etc) gone
- some others like (antispoof log for, block in log quick on $WAN from <bogons>, array key "wan" does not exist for (for all interfaces, like wan, lan, opt, etc...)
- Status changed from Feedback to Closed
No recent reports on supported versions, unless this can be reproduced on 2.4 it appears to be solved.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 