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

Firewall(self) as source in rules?

Scheduled Pinned Locked Moved General pfSense Questions
13 Posts 7 Posters 3.9k 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.
  • D
    Derelict LAYER 8 Netgate
    last edited by Mar 4, 2015, 5:05 PM

    I must put it in this firewall via pfsense 2.0.

    pfSense 2.0 doesn't have This Firewall (self).  It was added in 2.2.

    Packets from pfSense itself are generally passed since the packets are originating inside pfSense so it makes a lot more sense to use it as a destination than a source.

    https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting

    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
    • H
      heper
      last edited by Mar 4, 2015, 5:08 PM

      don't use 2.0 … it's ancient and unsupported

      1 Reply Last reply Reply Quote 0
      • R
        Ryure
        last edited by Mar 4, 2015, 5:17 PM

        Whoops, sorry. I meant 2.2, just had to fetch the documentation for the firewall to double check.

        @Derelict:

        I must put it in this firewall via pfsense 2.0.

        pfSense 2.0 doesn't have This Firewall (self).  It was added in 2.2.

        Packets from pfSense itself are generally passed since the packets are originating inside pfSense so it makes a lot more sense to use it as a destination than a source.

        https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting

        Okay, so in that case, is there a way to specific DHCP requests, NTP connections or DNS connections FROM the firewall to a network in the rules?

        1 Reply Last reply Reply Quote 0
        • D
          Derelict LAYER 8 Netgate
          last edited by Mar 4, 2015, 6:16 PM

          @Ryure:

          Okay, so in that case, is there a way to specific DHCP requests, NTP connections or DNS connections FROM the firewall to a network in the rules?

          Huh? A way to what?

          Did you even read that link?

          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
          • N
            Nullity
            last edited by Mar 4, 2015, 7:27 PM

            In theory, you could use packet marking to mark packets originating from LAN, then create 2 floating rules for outgoing WAN packets. One rule catches the marked packets from LAN and the other will catch packets originating from pfSense. Be careful with the order of floating rules as the last rule matched is the rule that is applied (unlike "first match" with Interface or "Quick" rules). So, the order should go from broadest rule (top) to the most precise rule (bottom).

            If you use outgoing NAT, be aware that outgoing packets on WAN will have translated the source address from LAN to WAN IP.

            Please correct any obvious misinformation in my posts.
            -Not a professional; an arrogant ignoramous.

            1 Reply Last reply Reply Quote 0
            • F
              fearnothing
              last edited by Mar 5, 2015, 5:28 AM

              @KOM:

              When trying to directly translate the rules, you should try to recreate the logical intent.  Those rules ensure that you can access the firewall on port 22 from LOC and NET.  The pfSense equivalent would be to allow all to LOC Address on port 22, and allow all to NET Address on port 22.  Usually the default LAN has an Allow All rule so you would really only need to set the rule on your LOC interface (assuming NET is your default LAN).

              As well as logical intent in terms of what the rule was supposed to achieve in a firewall sense, remember to consider the intent from a human sense. Why do they want port 22 to be able to access the firewall from both LOC and NET? I've had no experience with Shorewall but from the looks of it, configuration would be done over port 22 on the command line. PFSense's configuration is done via the web interface so while port 22 might still be useful (status checks, ping from the box etc) interpreting the intent of this rule would also mean making sure PFSense's administration page was accessible from both LOC and NET. And you should probably make sure it was locked down to HTTPS.

              1 Reply Last reply Reply Quote 0
              • R
                Ryure
                last edited by Mar 5, 2015, 1:52 PM

                @Derelict:

                @Ryure:

                Okay, so in that case, is there a way to specific DHCP requests, NTP connections or DNS connections FROM the firewall to a network in the rules?

                Huh? A way to what?

                Did you even read that link?

                My apologies, I did not mean to frustrate people here. I am still figuring out how to translate rules though I am almost done with just a few rules left. What I meant from that question was part of the rules sheet that I got.

                I just need to make rules for:

                Accepting DNS connections from Firewall to the network
                Allow DHCP request from firewall to campus network
                Allow ports 80 traffic FROM firewall itself for apt
                Allow email from firewall out.

                Just a few of the many left but the idea stands, they all originate from Firewall in the rules and since I am so inexperienced in this kind of stuff, I feel I need to turn to this forum for some help. I was able to easily make rules that involved opening ports to the firewall as a destination though I'm not sure about the other way around.

                1 Reply Last reply Reply Quote 0
                • D
                  doktornotor Banned
                  last edited by Mar 5, 2015, 4:29 PM

                  @Ryure:

                  I just need to make rules for:

                  Accepting DNS connections from Firewall to the network
                  Allow DHCP request from firewall to campus network
                  Allow ports 80 traffic FROM firewall itself for apt
                  Allow email from firewall out.

                  Why? All of this just works out of the box (unless you have screwed it via some badly designed floating rules).

                  1 Reply Last reply Reply Quote 0
                  • D
                    Derelict LAYER 8 Netgate
                    last edited by Mar 5, 2015, 5:06 PM

                    Again, did you even read that link?

                    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
                    • H
                      heper
                      last edited by Mar 5, 2015, 5:17 PM

                      i think whoever gave you that sheet with the current "linux' firewall rules, probably has no clue how a firewall should work, and made an overcomplicated mess of things.

                      do note that i personally know (almost) nothing about firewalling :)

                      1 Reply Last reply Reply Quote 0
                      13 out of 13
                      • First post
                        13/13
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                        This community forum collects and processes your personal information.
                        consent.not_received