Block literally everything by default



  • I have noticed that despite all Firewall Rules pages displaying "Everything that isn't explicitly passed is blocked by default" at the bottom of the page, either I am misunderstanding something or am correct to say that this isn't necessarily true.

    On the WAN rules page, I have put up "pass" rules for things like HTTP, HTTPS, IMAP, POP3, SMTP, etcetera after having done an nmap analysis of everything that goes out of the network. However, the thing is, I never had a rule in the WAN page where any protocol of any port is 'pass'. Before I did anything, the only two rules on the WAN rules page were the "Block private networks" and "Block bogon networks."

    Now, I do not remember if I did this myself, but the LAN page does have a rule with a description "Default LAN -> any" that accepts any port on any protocol..

    What I want to do is have literally everything blocked by default. No information of any kind in or out. Then I want to whitelist only specific ports of specific protocols. Right now, based on everything I have said thus far in this post, pfSense does not do that. I can quickly tell you that by opening up SubSpace/Continuum (computer game) and seeing if the entire server list is green or red. If it is all red, the firewall is successfully blocking everything. If they are all green, the firewall isn't working or something isn't configured right or something.


  • Rebel Alliance Developer Netgate

    You may have turned on UPnP which lets your internal systems open up ports automatically.

    By default, the only traffic allowed in WAN is traffic associated with connections that were opened from inside.

    So:

    Client A -> firewall -> Web Site B

    Will let traffic go from A to B and from B back to A on the specific ports associated with that one single connection.

    However, if someone tries:

    Random Site C -> firewall

    That would be denied.

    UPnP lets clients inside setup their own port forwards, which would explain the behavior you are seeing.




  • Rebel Alliance Developer Netgate

    Then there may be some misunderstanding in how you think that the firewall rules in pfSense, and stateful firewalls in general, work.

    If you have no locally hosted services (port forwards, local servers) then you should have no pass rules on WAN and nothing under Firewall > NAT on the Port Forwards tab.

    If you want to restrict traffic from clients on LAN, you need to remove the default rule which will allow all outbound traffic, and replace it with rules that only allow specific protocols to leave.

    After adjusting the rules that allow traffic in, you should reset the states under Diagnostics > States, to ensure that any existing connections will be blocked.



  • @jimp:

    Then there may be some misunderstanding in how you think that the firewall rules in pfSense, and stateful firewalls in general, work.

    If you have no locally hosted services (port forwards, local servers) then you should have no pass rules on WAN and nothing under Firewall > NAT on the Port Forwards tab.

    If you want to restrict traffic from clients on LAN, you need to remove the default rule which will allow all outbound traffic, and replace it with rules that only allow specific protocols to leave.

    After adjusting the rules that allow traffic in, you should reset the states under Diagnostics > States, to ensure that any existing connections will be blocked.

    Yes, this works, thank you very much!

    Please help me to understand one thing more: then what is the difference between forwarding ports on LAN vs WAN – why would you need to be able to forward ports or set rules in WAN? I can't think of a scenario where it would make a difference ... ?


  • Rebel Alliance Developer Netgate

    If you have a web server (for example) on your LAN, you need to forward port 80 on WAN to port 80 on a the server on your LAN.

    A more common example for you might be if you want to run a torrent client that requires connections from remote peers, you need a port forward to allow the connections in from the WAN to the client PC locally. (Or UPnP to handle this automatically)

    There are many more scenarios that that for forwarding ports between local interfaces and other weird things, but that's the gist of it.



  • @jimp:

    If you have a web server (for example) on your LAN, you need to forward port 80 on WAN to port 80 on a the server on your LAN.

    A more common example for you might be if you want to run a torrent client that requires connections from remote peers, you need a port forward to allow the connections in from the WAN to the client PC locally. (Or UPnP to handle this automatically)

    There are many more scenarios that that for forwarding ports between local interfaces and other weird things, but that's the gist of it.

    Starting to make sense, but how does one differentiate between a server and a client (in the context illustrated below)? Both send and receive data.

    ie. Half-Life Dedicated Server waits for players to connect, and does a lot work uploading to all the players.
    How is this any different from a player (aka client) sending data to the server and receiving data back?


  • Rebel Alliance Developer Netgate

    The distinction is in who initiates the connection.

    A torrent client is an odd case because it is a client (connects to other peers) and a server (other peers connect to it).

    If something waits for others to connect, it's generally a server that needs ports forwarded to it in order to accept the connections from clients.

    A client connects to the server, and it may send and receive data on that connection; Uploading and downloading have nothing to do with who is the client and who is the server.



  • Hmm, ok. Then it sounds like it has all to do with the initial state of the process. A client will establish a connection to something, and through that connection stuff can happen. But a server, which does not have any connections (and thus cannot just freely allow data to travel about), needs a client to connect to make it possible.

    Difference in initial state of being: client connects, server receives.

    And so WAN regulates the receiving or incoming, whereas (if you so please to have it put this way) LAN is about connecting or outgoing data. The opposite on both interfaces would be… well, or maybe it's like two layers.

    1. Internet
    2. WAN
    3. LAN

    You connect to a server and of course your connection goes right through WAN to Internet (but LAN interface is responsible for the restriction and flow of connection). When data comes in, it goes through WAN -- and if it's a client-connection, it skips the rules for WAN and is delivered to the LAN client. But if it's a server-connection, it checks with WAN rules to decide whether or not to allow the incoming connection request in (and if so, is it to the right machine on LAN).

    Gotcha.



  • it depends on whom initiated the SYN


Locked