Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSEC Firewall rule problem.

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    15 Posts 4 Posters 4.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • w0wW
      w0w
      last edited by

      
       <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
      gui.png_thumb

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

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

        1 Reply Last reply Reply Quote 0
        • w0wW
          w0w
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • E
            eri--
            last edited by

            I pushed a fix test with a newer snapshot.

            1 Reply Last reply Reply Quote 0
            • w0wW
              w0w
              last edited by

              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"

              1 Reply Last reply Reply Quote 0
              • S
                stilez
                last edited by

                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>

                1 Reply Last reply Reply Quote 0
                • w0wW
                  w0w
                  last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • S
                    stilez
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • w0wW
                      w0w
                      last edited by

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

                      1 Reply Last reply Reply Quote 0
                      • jimpJ
                        jimp Rebel Alliance Developer Netgate
                        last edited by

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

                        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                        Need help fast? Netgate Global Support!

                        Do not Chat/PM for help!

                        1 Reply Last reply Reply Quote 0
                        • w0wW
                          w0w
                          last edited by

                          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?

                          1 Reply Last reply Reply Quote 0
                          • jimpJ
                            jimp Rebel Alliance Developer Netgate
                            last edited by

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

                            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                            Need help fast? Netgate Global Support!

                            Do not Chat/PM for help!

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.