IPSEC Firewall rule problem.
-
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. -
I pushed a fix test with a newer snapshot.
-
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 successfulIPSEC 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" -
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>
-
stilez
If you have solution, why not to post it? -
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.
-
ermal
Any comments?
Should it be submitted in redmine or not? -
He said above it should be fixed on current snapshots. If it's not, then update the redmine ticket.
-
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? -
http://redmine.pfsense.org/issues/2883
