Firewall Rule Issues

  • Hello all,

    Before I start I must say I love Pfsense! A big thank you to all that is contributing to this incredible software. I've been in networking for a while now but I'm pretty new to the Pfsense world and I'm to the point of needing some help from the pros. I decided to purchase a Watchguard x750e and install Pfsense on it. My current setup is as follows, I have a modem feeding the firewall which is feeding a Netgear Nighthawk Router. Router is my DHCP server so Pfsense is acting just as a firewall. I know I can use Pfsense as a DHCP router but I decided to let my router take care of that function. It took a little bit of configuration but everything is working great now.

    So here's my problem, unless I'm wrong, firewall by default should block everything unless ruled otherwise correct? If that's the case I must be missing something in the firewall rules as I'm still seeing DoS attacks at my router, please see attachment from router logs. Router being inside the firewall shouldn't see any of this traffic. Under the Firewall rules I have two entries to block private networks and bogon networks. As suspected when I search for the entries in the firewall logs it does not pull them up which is why I'm thinking it's letting them through, it doesn't match any of the rules. I have created a rule to block all incoming IPV4/IPv6 connections but nothing seems to block them. I'm out of ideas as to how to stop these requests at the firewall. To be totally honest even though router is logging these attacks I don't even know if these legitimate errors. I was hoping maybe someone might have experienced a similar problem and can shine some light on to the subject. Appreciate all your help and thanks in advance!

  • LAYER 8 Netgate

    Post a diagram detailing how you have all this connected and post what you have actually placed in your WAN rules on pfSense.

    Traffic does not pass into pfSense WAN unless there is a rule passing it.

  • In WAN Rules I only have one port open for my web server. While troubleshooting it I've took down every WAN rule but the top two to ensure that's not what was causing it however it didn't help. First two rules were entered in automatically when I enabled them under private networks under the General configuration of WAN tab.

    ![WAN Rules.PNG](/public/imported_attachments/1/WAN Rules.PNG)
    ![WAN Rules.PNG_thumb](/public/imported_attachments/1/WAN Rules.PNG_thumb)

  • LAYER 8 Netgate

    If your addresses are really 192.168.0.X/24 then you have to at least disable the block RFC1918 on pfSense WAN.

    If the nighthawk is doing NAT then you need to port forward from pfSense to the nighthawk then on the nighthawk you need to port forward to the host.

    You're probably going about it one of the more difficult ways possible with the cascaded NAT routers.

    It's not very helpful posting rules then blocking out all the meaningful information. Absolutely nobody cares what inside RFC1918 addresses you are using. Not sure why you care. Hiding/changing them only complicates helping you. What you are seeing on the nighthawk's WAN port is completely dependent on the contents of the rule you blocked out.

  • Hope this doesn't come across as me being a jerk. I appreciate the feedback but how I setup my internal network has absolutely nothing to do with my current issue. I think you're missing the whole picture here. I didn't ask how can I make this work. Connectivity is not my problem. Sorry if I didn't make this clear with the previous post. As far as your comment of being a more difficult setup you're right I could have made it much easier or different but I have done a lot harder network configurations as a CCNP so that was never my worry.

    If you really wanna know why there is a port forwarding, it is on a different port and an isolated network which has a point to point connection to another device from the firewall. It has nothing to do with this issue. And yes you're right router is doing the NAT for that network. As I mentioned before the firewall is just a firewall in this setup.

    Back to the problem at hand, forget the IP scheme of the networks and how I have it setup. I have a point to point connection between the firewall and the router. Somehow firewall is not stopping a certain public IP addresses from getting to the router. Specifically packets with source IP address that is actually a broadcast address, which is why my router is not liking it. There are only 2 rules which belong to the private and bogon network blocks under WAN tab. Connection to this IP address is not being initiated from the inside so it should never bypass my firewall.

    Essentially to narrow it down even more I have taken it down everything on the network. Simple as 1 firewall with 2 rules under WAN for private networks, mentioned before, point to point connection to my router and a public IP address is still getting to my router. I just purchased a hub so I can wireshark the point to point connection to figure out exactly what information is in the packet but I was hoping maybe someone can shed some light on the subject from previous experience.


  • LAYER 8 Netgate

    If the only two rules on WAN are the Block RFC1918 and Block Bogons and you are still seeing traffic come through (new states) then you have something buggered up at layer 2 or have done something silly like System > Advanced, Firewall, Disable Firewall enabing router-only mode.

    If you still have the pass rule for the web server enable logging on it and see what it's really letting through.

    Past experience says if there are no pass rules, the traffic is blocked.

    You can also turn on logging of all the default rules in Status > System Logs, Settings.

    You don't need a hub. You can Diagnostics > Packet Capture on pfSense interfaces and download the pcaps for wireshark viewing.

  • You have given me several great options! Turned on enable logging for the pass rules. That should give me another log to comb through. I'm also looking into packet capture as we speak. Much appreciated thank you again!

Log in to reply