Living with "Default Deny" both ways



  • This is a sanity check.  I would be very grateful if someone would correct me or verify that I am not being extreme.

    The PFSense book makes it rather bluntly clear in 6.4.1 that "Default Deny" in both directions is the right answer.  I have done this rigidly and reverse engineered many applications and games but it is an amazingly time consuming when your family wants to use a new game or app, and although I have never failed, I often wonder if this is going to be the first time and we will be out of luck.

    However PFSense installs with Default Allow going out (Or used to, long time ago), and everything I have read on the PFSense forum seems to imply without saying it that this is what the writer is doing, not running default deny.

    Discussions, forum posts on game or application sites never have information that is useful for configuring PFSense.  Instead they talk about "Opening port X" without saying if they mean incoming (Which would also require forwarding) or outgoing.  Explanations on the PFSense site all seem to use the same terminology… "open".

    When I ask for clarification there is never an answer, as though I am asking something obvious or they don't know what I am talking about.  How should I interpret "Open port 1234"?

    Yes I am venting, but validation and a few wise words would be appreciated.

    Are there any tools I should be using other than the built in packet capture?

    Thanks.



  • Default deny is how the rules should behave if there are no rules.
    This does not refer to the default "allow-all out" on the LAN-interface.

    This affects the way you design rules.
    If you have a "default allow" policy you explicitly need to block traffic you don't want.
    If you forget a block rule you can unexpectedly allow traffic and potentially open up your network to attackers.

    If you work with a "default deny" policy than the worst that can happen is some of your own communication may not work.
    And then you will start investigating anyway.

    Regarding your question how to open port 1234. What do you want to do?
    Open port 1234 sound to me like you have an internal server, you need to create a portforward with an associated firewall rule.
    Maybe you need to reword your question more clearly.



  • GruensFroeschli, First, thank you.  You are hitting this as I need, regarding understanding.

    Regarding "Default deny is how the rules should behave if there are no rules.  This does not refer to the default "Allow-all out" on the LAN-interface."    Yes and OK, but this means that I have to have specific rules for everything that gets out (which is how I have been operating).  And your two sentences seem contradictory - if you have an "Allow-all out" on the LAN interface, then this is how the firewall behaves when there are no explicit rules.  You seem to be saying to have a "Default deny" rule at the bottom, but an "Allow-all out" higher up, which defeats the philosophy of default deny.  Perhaps a specific question is:  What do you mean by "This does not refer to the default "allow-all out" on the LAN-interface?  Doesn't this preclude, prohibit a default "allow-all out" on the LAN-interface?

    Regarding the port opening question, someone in my family needs or wants to access xyz or run abc application or game.  Examples of the things that I have figured out in the past are XBox360, the Steam gaming platform, the local public library system, team-viewer, some chat thing for an online course, or my employer's ancient CISCO VPN facility.  I have worked on VOIP unsuccessfully, and EA/Dice's "Battlefield 4" is the current challenge.  For most things I can find authoratative sounding recipes on forums or on the target site's support pages or on the PFSense site or forums, but it virtually never works as advertised.  Hours of experimentation and trying to follow wireshark output reveals subtleties or other ports, piecing experimental results, reading between the lines, guessing.  Then it typically works for years.

    I don't have any internal servers per-se, except to the extent to which the games are internal servers.  They sometimes want the central application server to contact the client unsolicited, I suppose so that it can be more distributed vs. concentrating traffic on them.  In the end only the XBox and EA (Battlefield) are like that so far.

    As you can pick up from my comments, I have not gotten to this point without working at it.  My assumption at this point is that I am somehow approaching this wrong or interpreting the goals wrong.  In my mind the server/software I am trying to work with could and should publish a clear, succinct list of what is required, but they don't - they seem to publish something with vague ambiguous language that does not work.  Although I may not like the holes that they want me to make, it should not be difficult to clearly communicate the requirements.

    In this thread I am not looking for a specific recipe of "To make Battlefield 4 work do this" (Although that would not be unwelcome), what I am looking for is a little mentoring so that I can support myself better.

    Does this help you help me?



  • Perhaps the specific example is the way to go, though I really want to become more capable to figure these out myself.  EA/DICE says that Battlefield 3 has the same requirements as Battlefield 4, though many people who run 3 fine don't work with 4.  The requirements provided are:

    "Enable the following online ports on your connection:"
    TCP: 80, 442, 9988, 20000-20100, 22990, 17502, 42127
    UCP: 3659, 14000-14016, 22990-23006, 25200-25300

    This PC running Battlefield is on its own subnet, I call it "Orange".  It also has the XBox on it, and that works fine, and a PC running Windows without any antivirus/malware protection.

    I am running 1.2.3.  I have not upgraded because it works well and I expect it to take a long day to make the move, probably plus trailing issues.

    My basic rule set blocks DNS except to PFSense, the rules that enable XBox360, and a "Deny everything left" at the bottom.  All block rules are logged.  NAT is set up for static port, and there is a forwarding rule from WAN to the XBox for a port that is not on the above list.

    I created rules to let the list from EA out.  It did not work.  The client put up messages saying "Why are you blocking me?" (Literally).

    I read something that suggested that 3659 needed to be forwarded from WAN to the Battlefield PC so that it can send stuff unsolicited.  So I created that forwarding rule under NAT / Port Forward.  It now gets further, but still does not work.  I noticed that it was trying to get out 10261.

    Someone monitored traffic and found that adding TCP 10161, 10171, 10181, 10191, 10201, 10211, 10221, 10231, 10241, 10251 10261, 10271, 10281, 10291, 10301, 10311 and UDP 10700, 17497-17499, 25200, 25903, 26200, 36653 did the trick and enabled it to work.  This is insane, especially in light of the list from EA, but being on an isolated subnet, I gave it a try.  It gets a step further, but does not work.

    Everything blocked is logged, and I see nothing logged.  There are spurious attempts at connection from the WAN to 80, 443, and various other random registered and ephemeral ports from all over the world but mostly from China every few minutes.  Nothing persistent, so I assume that this is just the normal dribble.  Some of them do repeat with a long timeout for a while.

    The same system works fine at a friends house, who is going through one of those little blue wireless router boxes (to a wired port).

    Thanks ahead for any comments.



  • May I offer a suggestion.  I am guessing, from your description, this pfSense install is protecting a home network.  If that is the case, I would recommend a less restrictive outbound policy and put the enforcement on inbound traffic.  You are most likely using NAT for your LAN's outbound traffic.  That means in order for an external attacker to make much progress into your network from outside, you would need port forward rules sending traffic to internal hosts.  I doubt you have that unless you are "hosting" games on an internal LAN server for external users.  If that is the case, things get more complicated.

    If you want a 100% bullet-proof network, then default-deny on both inbound and outbound traffic is great.  But as you are seeing, it can be a major pain to administer.  For a Fortune 500 company with a lot of users and with lots of confidential data to protect, administering such a default-deny scheme might be worth it.  But for most home users, my opinion is that the hassle outweighs the potential reward.  If you look at your rules today, you will see that in order to make your applications work correctly you have to open up a Swiss cheese collection of ports and protocols.  It is common for applications to frequently shift ports, so what works one minute may fail the next.  If you wind up with hundreds of open ports to dozens or hundreds of IP addresses, are you really much better off than just allowing a more or less "allow-all" policy from the LAN?  I know that from a security purist's point of view that is blasphemy, but there is theory and there is practically.  Do you want to administer your firewall 16 hours a day, or would you rather use your other applications (like the games) instead?

    Assuming you have a more plain vanilla home network, I would pretty much allow all outbound traffic from your LAN.  This would be a "default allow" rule on the LAN for outbound traffic.  You can restrict a few things like maybe point all machines to a handful of trusted DNS servers and restrict outbound port 53 DNS lookups to just those boxes, etc.  Same for outbound e-mail traffic (just restrict it to trusted servers).

    For the WAN side I would put in a place a "default deny" rule set.  This means only traffic you have explicitly created a rule for gets in.  In your case, with a NAT setup, this would mean only port-forward rules would be needed.  The stateful inspection technology within pfSense will automatically allow inbound replies to previously outbound requests.  Stated another way, it automatically allows the replies from the Internet for things requested by your LAN hosts.

    If you want extra protection for stuff like malware, run a tool like Snort or pfBlocker.  There are some posts in the Packages forum about these tools and others.

    Bill


  • LAYER 8 Global Moderator

    ^ Ditto.. This is a typical home setup and should be more than secure enough.  And is default setup for pfsense out of the box.



  • Yes, thank you both.  It will be a couple of days before I can fiddle with it to see how it goes.  It is a home network, I have a LAN (I think of as Green) with Linux, MacOS, and Windows machines with ESET Security Suite, some on an access-point configured wireless.  A "Yellow" with untrusted and insecure devices like cell phones and guests and its access point, and an Orange that I told you about - my son's gaming network and other evil suspect things that can stew in their own juice.

    You gave me what might be called an educated compromise, that while I could imagine, I had no basis for such a decision.  While I don't know you three from Adam, clearly from your position on the forum you know at least 100 times what I do, and the only experience I have is ten years of my tiny network.

    I'll add a post and let you know how it works out.

    I assume that I shouldn't touch uPNP with a ten foot pole?  It sounds like a wonderful idea that could work well with responsible and conservative clients, but that could be a disaster with a careless client, and a welcome mat for malware.  Do I have the right idea or can this be used wisely?


  • LAYER 8 Global Moderator

    Only thing I have ever enabled UPnP for was my son's ps3..  I locked down UPnP to only be able to open ports to his ps3 IP, etc.

    It can be a useful tool, secure I would not call it ;)  I would never think to allow it for a whole network - but if locked down to specific device and or even specific ports it can open up, etc. then it can be useful and not a gaping hole.

    Colors - did you run IPcop for a while.. They like to use colors Red, Green, Blue, Orange ;)  Use to love ipcop, then found pfsense years ago..



  • No IPCop, though it seems to have had alot of happy users.  I started with Coyote Linux, firewall on a floppy, worked great, then moved to smoothwall, similar but much better but in the same class, then decided to try PFSense based on my baloney filter deciding that it was the real McCoy.  Thought I had died and went to heaven.  A quality product with people who know what they are talking about.  Smoothwall called the interfaces Red and Green.  Not sure where I got Orange and Yellow, but it seemed to fit relative to level of risk/danger with what I used them for.  I look forward to moving to 2.x with the shared rules and more symetrical roles of interfaces, but this works very well right now.



  • Are your Green, Yellow, and Orange networks on separate interfaces or VLANs?  You could maybe set up outbound rules for each interface that way.  On your Orange gaming network just say heck with it and allow all Outbound.  On your Green network have it most restrictive and only open up ports you might use like 80, 443, 53, etc.

    I just went full Nazi on Outbound rules about a week ago and LOVE it.  I'm a home user but it's a great learning experience and translates well to the enterprise as well (if one works in IT and wants to use a home pfSense setup as valuable experience).

    Really not all that bad.


Log in to reply