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

    Firewall rules not working except on WAN . PFSENSE 2.2.2 behind vSphere

    Firewalling
    6
    14
    2.0k
    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.
    • KOMK
      KOM
      last edited by

      What happens if you use actual clients instead of using pfSense's own interfaces?  Your rules should block all IP4 traffic, but I suspect that pfSense exempts its own interfaces or this would not work.

      1 Reply Last reply Reply Quote 0
      • F
        Fetakungen
        last edited by

        it works aswell…

        All rules except them on wan make no difference what so ever.

        I'll install 2.1.5 later tonight to see if it's the same..

        1 Reply Last reply Reply Quote 0
        • KOMK
          KOM
          last edited by

          Also, you should simplify things by removing the block rule you have on those two interfaces.  Everything not explicitly allowed is already blocked, so those rules are redundant.  I'm wondering if pf is even running.  Anything in your System log?

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

            and what physical network do these 4 interfaces connect too..  Is that a lagg to the physical switch?  What is the configuration on the physical switch ports?

            I sure would not do it that way.  I break out my vswitches to specific physical nics, which are on their own vlans and then 1 is a trunk that has vlan that is running on that physical network.

            See the trunk on the wlan port group.

            I would really break out your vmkern and vmotion stuff to its own physical nic - I saw a huge performance increase moving stuff to and from datastore and physical machines when I broke out the vmkern to its own physical nic.

            esxinetwork.png
            esxinetwork.png_thumb

            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.7.2, 24.11

            1 Reply Last reply Reply Quote 0
            • H
              Harvy66
              last edited by

              Question. Does a ping originating from the firewall actually obey the firewall rules? I was under the impression that the rules are applied on data coming in from the physical interface.

              1 Reply Last reply Reply Quote 0
              • F
                Fetakungen
                last edited by

                The reason for this is that the nics are load balanced by esxi, The nics are connected to trunks. This works great and provides a good failsafe and provides all kind of pros like all switchports may have same config, subnets are handled with software and not nics..

                The Esxi networking is not the problem, Atleast not the switch when pinging from a net to another it never leaves router so it's related to pfsense / it's "hardware".

                Also this problem occurs on my system where internal lan doesnt even have a connected nic.

                Regarding the rules i know KOM but just to show that it doesnt give a shit about my rules…

                Harry, You choose from which interface you ping as you see in the print , from SERVER net to Public net.

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

                  If you say so..  Doesn't seem like it works great to me.. While mine is working fine your here asking why your firewall rules are not working ;)

                  How would your switch ports have the same configs?  The different ports on your switch that have physical machines in the specific vlans would have to be setup.

                  Why don't you just put vnics for pfsense in your different vswitches?

                  "pinging from a net to another it never leaves router"

                  What router?  You have another router on the physical network?

                  As to pinging stuff - if your pinging from pfsense, what rule do you think would block.. from firewall to devices on that segment there is no block.. Rules on interfaces are INBOUND rules from that segment too pfsense, not from pfsense to that segment.

                  edit:  So I disabled all my rules on the dmz segment (192.168.3.0/24)..  So pfsense if using that interface as source can still ping stuff in my lan (192.168.1.0/24) since those rules do not apply to pfsense itself.

                  But as you see stuff from dmz can not ping stuff in lan, but lan can still ping it because the lan rules do not block it from going to dmz

                  dmzrules.png
                  dmzrules.png_thumb
                  pingfrompfsense.png
                  pingfrompfsense.png_thumb
                  pingfromboxondmz.png
                  pingfromboxondmz.png_thumb

                  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.7.2, 24.11

                  1 Reply Last reply Reply Quote 0
                  • F
                    Fetakungen
                    last edited by

                    Well i'm sorry tested it now and apperently pfsense is always able to ping itself between interfaces as you stated.

                    What i meant with "never leave the router" is that when i ping from interface to interface it never leaves pfsense therefore switching not the issue.

                    Regardning the nics. With only 4 nics in the machine i dont want to waste 1 on for example managment which doesnt need much , vmotion is rarley used and when it is it could sure use more than 1, also for storage more then 1 is prefered and also Failsafe for all nets. I dont see why teaming would bother except if it high end gear at full load, Then a separate mgmt and vmotion for example is prefered or even needed.

                    The internal traffic was blocked as supposed to except between Public and external hosts..

                    I can ping 193.10.29.36 even tho public is blocked meanwhile i cant access anything from Public net as supposed to.. Which was what caught my attention in the first place…

                    Edit: i seem to have gotten it all backwards..

                    "But as you see stuff from dmz can not ping stuff in lan, but lan can still ping it because the lan rules do not block it from going to dmz"

                    But if i setup a block rule in public net any / any it shouldnt be able to respond to a ping since everything going out should be blocked?..

                    1 Reply Last reply Reply Quote 0
                    • KOMK
                      KOM
                      last edited by

                      Also remember that pf is a stateful firewall.  Existing states will be active regardless of any rule changes.  When doing testing, you may want to reset the states after you make a rule change (Diagnostics - States - Reset States).

                      1 Reply Last reply Reply Quote 0
                      • C
                        cmb
                        last edited by

                        @Fetakungen:

                        But if i setup a block rule in public net any / any it shouldnt be able to respond to a ping since everything going out should be blocked?..

                        No, that's not how stateful firewalls work. Replies to permitted traffic aren't evaluated by the ruleset.

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