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

    Interface feature for blocking RFC1918 or custom rule?

    Scheduled Pinned Locked Moved Firewalling
    10 Posts 3 Posters 821 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.
    • ?
      A Former User
      last edited by

      To maintain segmentation between interfaces (both physical and VLANs) on my pfSense, I have created a block rule for each interface that has the respective interface as the source and RFC 1918 nets defined as the destination. I noticed on the interface pages a feature called 'block private networks and loopback addresses'. The feature adds a block rule for the interface, however it defines the source as RFC 1918 and 'any' as the destination. I am trying to discern if there is any benefit to my custom rule vs this feature, and if I should just use the interface feature to isolate my subnets?

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        The interface checkbox adds rules that block connections into that interface with an RFC1918 source address. It is intended for use on public WANs.

        It sounds like you want to block RFC1918 destinations instead. An Alias and a block rule is perfect there.

        I actually prefer using a reject rule instead of a block so any inside clients get a RST (connection refused) instead of just hanging.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • ?
          A Former User
          last edited by

          Would an RST be a give away to user that a network is behind the address they are trying to resolve?

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            I am talking about connections from the inside that are hitting your block/reject RFC1918 rule.

            If you reject source LAN net dest RFC1918 they will get a RST no matter what address they try that is RFC1918.

            If you have enemies inside your network it is up to you to determine the threat model. The whole "stealth" thing is pretty overblown, IMHO.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • ?
              A Former User
              last edited by

              Thank you. Good points.

              1 Reply Last reply Reply Quote 0
              • johnpozJ
                johnpoz LAYER 8 Global Moderator
                last edited by

                Firewalls normally do not send RST for a port that is closed.. Hosts will quite often - windows for sure does.. Hit windows box on port that is not listening with firewall not on and you get a RST..

                "have created a block rule for each interface that has the respective interface as the source and RFC 1918 nets defined as the destination."

                Huh?  Please post this rule.. That rule would never trigger since traffic is only evaluated inbound to an interface - did you create these rules on the floating tab picking the interface?  And use outbound direction?  Do you mean you created a rule on each interface with source that respective net and dest rf1918?  This would yes keep your vlans from talking to each other.  I have sim rules on my vlans I don't want to talk to other vlans, etc.

                Be it you reject or just let pfsense drop it is up to you.. I would not reject to public internet… not so much of trying to stay "stealth" ;)  With Derelict that term is nothing but a bunch of hype.. But you don't want to be sending out traffic for every stray noise packet that hits your wan ;)  Be nuts to do that!!!  But on lan can be helpful to see the RST come right from pfsense, vs no answer etc.

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.8, 24.11

                1 Reply Last reply Reply Quote 0
                • ?
                  A Former User
                  last edited by

                  Thanks JohnPoz.

                  For example. The block rule on my LAN looks like this.
                  Block IPV4 * LAN net * RFC1918 nets "

                  I have repeated this on every interface replacing the source with the respective interface. The way I understand it, the block is protecting other nets from the interface. Should I invert that logic and protect the interface from other nets? Do you recommend that I do something like this instead?

                  Reject IPV4 * RFC1918 nets * LAN net *

                  Thanks.

                  1 Reply Last reply Reply Quote 0
                  • johnpozJ
                    johnpoz LAYER 8 Global Moderator
                    last edited by

                    screenshots are WAY better..

                    your first rule is correct if on the lan net.

                    Your second rule would only be good if NOT on the lan net with dest of lan net, and makes no sense really unless you had downstream networks off this interface..

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 24.11 | Lab VMs 2.8, 24.11

                    1 Reply Last reply Reply Quote 0
                    • ?
                      A Former User
                      last edited by

                      Good. Thanks. The rule has been blocking between nets so I figured I was doing something right. I just wasn't sure if there was a better way of blocking inter-lan traffic.

                      I will just make sure that the rule is rejecting instead of blocking in the LAN as suggested.

                      1 Reply Last reply Reply Quote 0
                      • johnpozJ
                        johnpoz LAYER 8 Global Moderator
                        last edited by

                        you do not have to reject - that is up to you.

                        An intelligent man is sometimes forced to be drunk to spend time with his fools
                        If you get confused: Listen to the Music Play
                        Please don't Chat/PM me for help, unless mod related
                        SG-4860 24.11 | Lab VMs 2.8, 24.11

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