IPSEC Firewall rule problem.

w0w

From time to time I get errors in log
Mar 9 21:49:25 php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:188: syntax error - The line in question reads [188]: block return in log quick on $IPsec inet from any to !/ label "USER_RULE: disable LAN, Enable WAN"
This rule is created about 3 months ago and notices in log appeared only about month ago, when I've upgraded pfsense.
May be it just wrong rule or there is a problem in pfsense?

eri--

What does the rule contain?

jimp

"to !/ label"

Looks like that particular rule is invalid. What exactly does that rule look like in the GUI? What about in your config.xml?

w0w


 <rule><id><type>reject</type>
			<interface>enc0</interface>
			<ipprotocol>inet</ipprotocol>
			 <tag><tagged><max><max-src-nodes><max-src-conn><max-src-states><statetimeout><statetype>keep state</statetype>

			<source>
				 <any><destination><network>wan</network></destination></any></statetimeout></max-src-states></max-src-conn></max-src-nodes></max></tagged></tag></id></rule>

gui.png_thumb

eri--

Is your WAN fluctuating during this time?
Meaning going up/down or renewing it lease?

w0w

I think yes, but I when I physically disconnect WAN cable or just restart PPPoE (my WAN is PPPoE) no such error in log.
I'll try later to start ipsec session and then disconnect wan.

eri--

I pushed a fix test with a newer snapshot.

w0w

I've increased log size, so now I have more information.
Looks like I receive two similar errors during the boot.

System Log:

Mar 13 18:54:36	php: : DynDns: updatedns() starting
Mar 13 18:54:35	check_reload_status: Rewriting resolv.conf
Mar 13 18:54:35	check_reload_status: Restarting ipsec tunnels
Mar 13 18:54:35	php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:188: syntax error - The line in question reads [188]: block return in log quick on $IPsec inet from any to !/ label "USER_RULE: Disable LAN, Enable WAN"
Mar 13 18:54:35	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:35	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:35	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:35	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:35	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:35	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:35	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:35	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:35	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:34	check_reload_status: Updating all dyndns
Mar 13 18:54:33	kernel: em1: link state changed to UP
Mar 13 18:54:33	check_reload_status: Linkup starting em1
Mar 13 18:54:31	php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:188: syntax error - The line in question reads [188]: block return in log quick on $IPsec inet from any to !/ label "USER_RULE: Disable LAN, Enable WAN"
Mar 13 18:54:31	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:31	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:31	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:31	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:31	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:31	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:31	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:31	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:31	php: : Could not find IPv4 gateway for interface (wan).
Mar 13 18:54:31	kernel: em0: link state changed to UP
Mar 13 18:54:31	check_reload_status: Linkup starting em0
Mar 13 18:54:30	kernel: pflog0: promiscuous mode enabled
Mar 13 18:54:30	php: : Resyncing OpenVPN instances.
Mar 13 18:54:30	php: : Starting 3gstats.php on device '' for interface 'wan'
Mar 13 18:54:29	sshlockout[8283]: sshlockout/webConfigurator v3.0 starting up
Mar 13 18:54:29	sshd[8083]: Server listening on 0.0.0.0 port 22.

PPP log (WAN)

Mar 13 18:54:35	ppp: [wan_link0] LCP: state change Starting --> Req-Sent
Mar 13 18:54:35	ppp: [wan_link0] LCP: Up event
Mar 13 18:54:35	ppp: [wan_link0] Link: UP event
Mar 13 18:54:35	ppp: [wan_link0] PPPoE: connection successful

IPSEC log

Mar 13 18:54:35	racoon: INFO: Reading configuration from "/var/etc/ipsec/racoon.conf"
Mar 13 18:54:35	racoon: INFO: @(#)This product linked OpenSSL 1.0.1e 11 Feb 2013 (http://www.openssl.org/)
Mar 13 18:54:35	racoon: INFO: @(#)ipsec-tools 0.8.1 (http://ipsec-tools.sourceforge.net)

IPSEC rules are loaded before wan is connected and racoon started. Could it be a problem?

P.S. This is on "2.1-BETA1 (i386)
built on Wed Mar 13 08:15:15 EDT 2013
FreeBSD 8.3-RELEASE-p6"

stilez

I hit the !/ artifact last year and traced it to (from memory) a bug possibly related to PPPoE (and some other WAN networks?) having the WAN subnet ending up undefined under some or all conditions, which caused this problem when pfsense tried to create the pf rules string.

So it was trying to produce a clause in the rule something like "from any to !{{$NETWORK_IP}}/{{$NETWORK_CIDR_BITS}} ….." only the two variable terms are evaluating to null or empty strings giving a rule with the "to !/" artifact in it.

And indeed there's a rule in the OP's rules dump that is trying to include conditions such as " <not><wan subnet="">" or similar, and the OP also has PPPoE.

Separate, I looked last year into why it "randomly" seemed to start. For me it was because of a second issue. It seemed there was a bug of some kind in advanced or usual PPP config (similar to the MTU non-saving issue?), that some data may in some circumstances not be saved in the PPP config, when PPP settings are edited, and instead when PPP settings are saved, they got some incorrectly blanked data instead.

I didn't find exact fixes but that was the issues behind it. The solution for me was to mod the code to allow explicit entry of a WAN subnet for all kinds of WAN, which fixed it.</wan></not>

w0w

stilez
If you have solution, why not to post it?

stilez

That's the past tense. The mod "was". I did a crude hack and about 2 weeks ago I moved from 2.0.x to 2.1 and with a new code base, finding exactly what I did a year or 2 ago isn't easy. I do remember what caused it, because it took a lot of time to track down, though. Annoying bug, it was. Hopefully the above info will let someone else fix it properly.

w0w

ermal
Any comments?
Should it be submitted in redmine or not?

jimp

He said above it should be fixed on current snapshots. If it's not, then update the redmine ticket.

w0w

It's not fixed and I've provided NEW logs with error and logs are made on current snapshots.
I am not sure what was redmine ticket number if it was. I have not created any tickets about this problem, because I did not think that it is a bug. Is there some ticket already with similar problem?

jimp

http://redmine.pfsense.org/issues/2883