Firewall rule not blocking



  • 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)



  • 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.



  • 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.



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



  • 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.



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



  • 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



  • Glad to help.


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy