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

    Firewall rule not blocking

    Scheduled Pinned Locked Moved Firewalling
    8 Posts 2 Posters 2.3k 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.
    • S
      skipchang
      last edited by

      I'm at my wit'n end trying to trouble shoot this issue:

      Attached is the firewall rule for the lab_integration interface (10.1.0.1./16)

      Configuration is as follows:
      1.  Multiple VLANs assigned to the physical LAN device.
      2.  Each VLAN on a separate and unique subnet
      3.  Single WAN interface

      Attached screen shot firewall rule description:
      1.  Allow ICMP to any interface
      2.  Allow DNS lookup to the internal DNS servers on a different subnet.  The alias AMGT_DNS defines two different DNS servers on the 10.0.0.0/16 subnet
      3.  Allow NTP sync to the internal NTP server on a different subnet.  The alias NTP_SERVER points to 10.0.1.20.
      4.  Allow NFS interface to the internal NFS server on a different subnet.  The alias Internal_Servers defines two different NFS servers on the 10.0.0.0/16 subnet
      5.  Allow SSH/SCP interface to the Users address (10.0.0.0/16).
      6.  Block everything else.

      Based on this set of rules, I would expect the firewall to not allow any traffic to the Internet.  However, when I run "curl www.google.com", I get the response back from google.  I looked at the firewall logs and nothing show us.  However, when I look at the diagnostics–>states and filter on the machine on the 10.1.0.0/16 network (machine IP address: 10.1.200.1), I see that NAT occurred from 10.1.200.1-->127.0.0.1:xxxx  .  I don't get this at all.

      I could really use the help figuring this out.

      Thanks,
      Skip
      ![Screen Shot 2017-12-06 at 10.16.06 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2017-12-06 at 10.16.06 PM.png_thumb)
      ![Screen Shot 2017-12-06 at 10.16.06 PM.png](/public/imported_attachments/1/Screen Shot 2017-12-06 at 10.16.06 PM.png)

      1 Reply Last reply Reply Quote 0
      • KOMK
        KOM
        last edited by

        You don't need that last rule since there is a hidden Default Deny rule on all interfaces.

        Did you reset your states after you made your firewall rule changes?  Established states will not be affected by a rule update.

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

          Yes.  I did reset the states after the firewall rule changes.  No changes in behavior.

          I'm scheduling a reboot of the pfsense box this weekend to see if that clears it up.

          1 Reply Last reply Reply Quote 0
          • KOMK
            KOM
            last edited by

            Those rules should block WWW traffic on that interface.  Are you sure you're on the interface and not some other VLAN?

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

              Yes.  I'm sure.  Just for yucks, I moved the "block all" rule to the top and it stopped the curl command.

              I will be rebooting the pfsense box tonight and see if that clears things up.

              In addition, from the machine on the VLAN, here's the default routes:

              [root@localhost ~]# route -n
              Kernel IP routing table
              Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
              10.1.0.0        0.0.0.0        255.255.0.0    U    1      0        0 eth0
              0.0.0.0        10.1.1.1        0.0.0.0        UG    0      0        0 eth0

              Also, when I ran "curl www.google.com", here's the firewall log and the state log:

              Firewall log:
              2 Matched Firewall Log Entries. (Maximum 2000) Pause
              Action Time Interface Source Destination Protocol
              Dec 7 10:29:42 LAB_INTEGRATION 10.1.200.1:42270 10.0.1.22:53 UDP
              Dec 7 10:29:08 LAB_INTEGRATION 10.1.200.1:45254 10.0.1.22:53 UDP

              State Log:
              States
              Interface Protocol Source (Original Source) -> Destination (Original Destination) State Packets Bytes
              LAB_INTEGRATION udp 10.1.200.1:58220 -> 10.0.1.22:53 SINGLE:MULTIPLE 2 / 2 120 B / 164 B
              USERS udp 10.1.200.1:58220 -> 10.0.1.22:53 MULTIPLE:SINGLE 2 / 2 120 B / 164 B
              LAB_INTEGRATION tcp 10.1.200.1:55985 -> 127.0.0.1:3128 (172.217.1.196:80) FIN_WAIT_2:FIN_WAIT_2 16 / 15 1017 B / 13 KiB
              LAB_INTEGRATION tcp 10.1.200.1:813 -> 10.0.1.11:2049 ESTABLISHED:ESTABLISHED 28.851 K / 24.415 K 5.11 MiB / 5.83 MiB
              USERS tcp 10.1.200.1:813 -> 10.0.1.11:2049 ESTABLISHED:ESTABLISHED 28.851 K / 24.415 K 5.11 MiB / 5.83 MiB
              USERS tcp 10.0.4.1:52516 -> 10.1.200.1:22 ESTABLISHED:ESTABLISHED 359 / 233 26 KiB / 98 KiB
              LAB_INTEGRATION tcp 10.0.4.1:52516 -> 10.1.200.1:22 ESTABLISHED:ESTABLISHED 359 / 233 26 KiB / 98 KiB

              One of my main question is the route to 127.0.0.1 on the third line of the filtered states log.

              1 Reply Last reply Reply Quote 0
              • KOMK
                KOM
                last edited by

                That's a redirect to squid web proxy which listens on tcp/3128.

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

                  KOM,

                  That was the key.  What I thought was seeing was the cached page for the sites from the squid proxy.

                  Thanks for getting my head out of my #@$.

                  Skip

                  1 Reply Last reply Reply Quote 0
                  • KOMK
                    KOM
                    last edited by

                    Glad to help.

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