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

    Passing DMZ IP to !LAN rule blocks all traffic

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    8 Posts 3 Posters 3.7k 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.
    • H Offline
      hase
      last edited by

      Running version 2.1-beta1 from Feb 2nd snapshot.

      DMZ rules:
      Block IPv4 * DMZ net * LAN net * * none   Block DMZ to LAN traffic
      Block IPv4 * DMZ net * WLAN net * * none   Block DMZ to WLAN traffic
      Pass  IPv4 UDP 10.54.3.5 * DMZ address 53 (DNS) * none    
      Pass  IPv4 ICMP 10.54.3.5 * DMZ address * * none    
      Pass  IPv4 TCP 10.54.3.5 * ! LAN net 80 (HTTP) * none   Allow DMZ to HTTP
      Pass  IPv4 TCP 10.54.3.5 * ! LAN net 443 (HTTPS) * none   Allow DMZ to HTTPS
      Pass  IPv4 TCP 10.54.3.5 * ! LAN net 21 (FTP) * none   Allow DMZ to FTP

      But, attempts to web to google are blocked:
      Feb 3 18:18:54 DMZ     10.54.3.5:49747     74.125.142.101:80 TCP:S
      Feb 3 18:18:57 DMZ     10.54.3.5:49747     74.125.142.101:80 TCP:S

      If I make the Pass rules "any" destination, web to google works.  i.e.:
      Pass  IPv4 TCP 10.54.3.5 * * 80 (HTTP) * none   Allow DMZ to HTTP

      Now, I know that having the block rules are stopping the traffic I want blocked, but as a good firewall admin, I don't want any rule that permits traffic that shouldn't be allowed.  Am I misunderstanding the "not" function?  Is this a bug I can help fix?

      Thanks!

      1 Reply Last reply Reply Quote 0
      • AhnHELA Offline
        AhnHEL
        last edited by

        I'm seeing something wrong with !LAN as well.

        This works:

        PROTO          SOURCE    PORT        DEST            PORT      GATEWAY    QUEUE      DESCRIPTION
        PASS    IPv4 TCP/UDP    LAN NET      *      LAN ADDRESS    53(DNS)        *            none        ALLOW DNS
        BLOCK    IPv4 TCP/UDP    LAN NET      *              *              53(DNS)        *            none        BLOCK ROGUE DNS
        PASS    IPv4      *          LAN NET      *              *                  *            *              none        LAN TO ANY

        But for the life of me I cannot get this to work:

        PROTO          SOURCE    PORT        DEST            PORT      GATEWAY    QUEUE      DESCRIPTION
        BLOCK    IPv4 TCP/UDP    LAN NET      *      !LAN ADDRESS    53(DNS)        *            none        BLOCK ROGUE DNS
        PASS    IPv4      *          LAN NET      *              *                  *            *              none        LAN TO ANY

        Using the !LAN ADDRESS, I'm getting blocked out from using DNS and I get this in the firewall logs.

        X      Feb 3 14:36:37 LAN USER_RULE Block Rogue DNS (Log) (@121)  192.168.1.5:58560 192.168.1.1:53 UDP

        I'm resetting States and closing browser in between rule changes.

        AhnHEL (Angel)

        1 Reply Last reply Reply Quote 0
        • H Offline
          hase
          last edited by

          Looks like you're seeing the same thing I am.  I should also clarify, it's not blocking all traffic, it just acts like !LAN is an empty set, effectively nullifying the pass rule it's in.

          1 Reply Last reply Reply Quote 0
          • P Offline
            phil.davis
            last edited by

            +1 - I have to add an explicit pass rule before the !LAN Address blocking rule to get DNS and be able to post this message.
            The firewall log shows:

            Feb 4 08:26:46 LAN	USER_RULE Block rogue DNS (@82)	10.49.112.111:49218	10.49.112.250:53	UDP

            But 10.49.112.250 in the pfSense LAN Address.
            The user rules (including the workaround) are:

            anchor "userrules/*" all
pass in quick on vr1 reply-to (vr1 192.168.12.1) inet proto tcp from <inf_inet_ips> to any flags S/SA keep state label "USER_RULE: Allow incoming VPN"
pass in quick on vr0 inet proto tcp from 10.49.112.0/24 to 10.49.112.250 port = domain flags S/SA keep state label "USER_RULE: Allow DNS to pfSense"
pass in quick on vr0 inet proto udp from 10.49.112.0/24 to 10.49.112.250 port = domain keep state label "USER_RULE: Allow DNS to pfSense"
block drop in log quick on vr0 inet proto tcp from 10.49.112.0/24 to 10.49.112.250 port = domain label "USER_RULE: Block rogue DNS"
block drop in log quick on vr0 inet proto udp from 10.49.112.0/24 to 10.49.112.250 port = domain label "USER_RULE: Block rogue DNS"
pass in quick on vr0 inet from 10.49.112.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"
pass in quick on openvpn inet all flags S/SA keep state label "USER_RULE: Allow all on OpenVPN"
block drop in log quick on ath0_wlan0 inet proto tcp from 10.49.113.0/24 to ! 10.49.113.250 port = domain label "USER_RULE: Block rogue DNS"
block drop in log quick on ath0_wlan0 inet proto udp from 10.49.113.0/24 to ! 10.49.113.250 port = domain label "USER_RULE: Block rogue DNS"
pass in quick on ath0_wlan0 inet from 10.49.113.0/24 to any flags S/SA keep state label "USER_RULE: Allow all from WiFi"</inf_inet_ips>

            These ones should have a "!" not in them:

            block drop in log quick on vr0 inet proto tcp from 10.49.112.0/24 to 10.49.112.250 port = domain label "USER_RULE: Block rogue DNS"
block drop in log quick on vr0 inet proto udp from 10.49.112.0/24 to 10.49.112.250 port = domain label "USER_RULE: Block rogue DNS"

            Interestingly, the equivalent rule on WiFi (ath0_wlan0) is correct and WiFi DNS is doing the correct thing.
            Screenshots of before (problem) and after (workaround) attached.

            RuleSampleDNS.png
            RuleSampleDNS.png_thumb
            RuleSampleDNS2.png
            RuleSampleDNS2.png_thumb

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • P Offline
              phil.davis
              last edited by

              This does not seem to be a new problem. I tried on a system running:
              2.1-BETA1 (i386)
              built on Wed Dec 12 10:59:14 EST 2012
              I added a pass rule to "not LAN address" - but /tmp/rules.debug has:

              pass  in  quick  on $LAN inet proto tcp  from any to 10.49.32.250 flags S/SA keep state  label "USER_RULE: Allow any not to LAN address - testing"

              There it should be "! 10.49.32.250"
              filter.inc filter_generate_address has code for:

              		if(strstr($rule[$target]['network'], "opt")) {

              and that section implements the "not", but the "else" of that does not do the "not".
              It looks like it has been that way a long time - will submit a pull request soon.

              As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
              If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

              1 Reply Last reply Reply Quote 0
              • H Offline
                hase
                last edited by

                Well… great! I'm glad it wasn't just my fat fingers vexing me.  Thanks for running that down.  I'm no dev but is there anything I can do to help from here?

                1 Reply Last reply Reply Quote 0
                • AhnHELA Offline
                  AhnHEL
                  last edited by

                  To be honest this has been like this for quite some time, even since I started using 2.1 many, many months ago.  In 1.2.3 and 2.0, I always used the !Not rule to block rogue DNS but since testing 2.1, this has never worked so I just created separate pass and block rules and have since forgotten that it was not working until the OP reminded me.

                  Might require its own thread but I'm having a similar issue on one of my boxes where wifi is bridged to LAN.  Setting up firewall rules in the OpenVPN tab are useless and ignored.  I have to setup OpenVPN rules in the Floating Tab in order to have rules obeyed for OpenVPN.

                  Similar setup on my other box but without the wifi bridge works as intended and OpenVPN tab rules are obeyed, so I can only guess that its the wifi bridge that is causing OpenVPN rules to be ignored.

                  AhnHEL (Angel)

                  1 Reply Last reply Reply Quote 0
                  • P Offline
                    phil.davis
                    last edited by

                    Rules on any interface called optn (usually people have renamed them WiFi etc, but they are called opt1, opt2 etc underneath) were working fine. It is only the case for the "builtin" interfaces called wan and lan that was broken.
                    I have made a pull request to fix it: https://github.com/bsdperimeter/pfsense/pull/373
                    Yes, it turns out it has been broken in the 2.1/mainline branch since April 2011! (see comments on pull request for links to that)

                    As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                    If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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